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This  document  Is  a  collection  of  Internal  working 
notes  produced  by  members  of  the  Computer  Security  Branch, 
Directorate  of  Information  Systems  Technology, . Deputy  for 
Command  and  Management  Systems,  during  the  period  of 
August  -  November  1972. 

Although  the  preliminary  nature  of  these  notes  Is 
emphasized,  we  hope  they  will  be  an  aid  to  understanding 
the  direction  of  ongoing  computer  security  efforts,  until 
such  time  as  more  complete  results  are  available.  Three 
efforts  now  underway  have  been  Influenced  by  the  Ideas 
expressed  hereV  and  future  products  can  be  anticipated} 

a.  ESD-TR-73-51,  Computer  Security  Technology 
Planning  Study,  by  James  P.  Anderson,  dated  October  1972. 

b.  MITRE-MTR-25k7,  "Secure  Computer  Systems: 
Mathematical  Foundations'1/  by  D.  E.  Bell  and  L.  J. 
LaPadula. 

c.  Final  report  from  Case  Western  Reserve  University 
under  the  ESD(MCI)  Statement  of  Work,  "Abstract  Model  for 
Secure  Computer  Systems". 


REVIEW  AND  APPROVAL 


Publication  of  this  report  does  not  constitute  Air 
Force  approval  of  the  report's  finding  or  conclusions.  It 
Is  published  only  for  the  exchange  and  stimulation  of 
Ideas. 


Director,  Information  Systems  Technology 
Deputy  for  Command  A  Management  Systems 
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NOTES  ON  AN  APPROACH  FOR  DESIGN  OF  SECURE 
MILITARY  ADP  SYSTEMS 


Intr.flductJ.ttn 

The  military  has  a  heavy  responsibility  for 
protection  of  Information  In  Its  shared  computer  systems. 
The  military  must  insure  the  security  of  Its  computer 
systems  before  they  are  put  Into  operational  use.  That 
Is,  the  security  must  be  "certified",  since  once  military 
Information  is  lost  it  Is  I rretrlevable  and  there  are  no 
legal  remedies  for  redress. 

Most  contemporary  shared  computer  systems  are  not 
secure  because  security  was  not  a  mandantory  requirement 
of  the  Initial  hardware  and  software  design.  The  military 
has  reasonably  effective  physical,  communication,  and 
personnel  security,  so  that  the  nub  of  our  computer 
security  problem  Is  ti*e  Information  access  controls  In  the 
operating  system  and  supporting  hardware.  We  primarily 
need  an  effective  means  for  enforcing  very  simple 
protection  relationships,  (e.g.,  user  clearance  level  must 
be  greater  than  or  equal  to  the  classification  level  of 
accessed  Information);  however,  we  do  not  require 
solutions  to  some  of  the  more  complex  protection  problems 
such  as  mutually  suspicious  processes. 

Based  on  the  work  of  people  like  Butler  Lampson  we 
have  espoused  three  design  principles  as  a  basis  for 
adequate  security  controls: 

a.  Complete  Mediation  --  The  system  must  provide 
complete  mediation  of  information  references,  l.e.,  must 
interpose  itself  between  any  reference  to  sensitive  data 
and  accession  of  that  data.  All  references  must  be 
validated  by  those  portions  of  the  system  hardware  and 
software  responsible  for  security. 


h.  isolation  —  These  validation  operators,  a 
"security  kernel",  must  be  an  Isolated,  tamper-proof 
component  of  the  system.  This  kernel  must  provide  a 
unique,  protected  identity  for  each  user  who  generates 
references,  and  must  protect  the  reference-validating 
algorithms. 
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c.  Slmol let  tv  --  The  security  kernel  must  be  simple 
enough  for  effective  certification.  The  demonstrably 
complete  logical  design  should  be  Implemented  as  a  small 
set  of  simple  primitive  operations  and  system  data  base 
structures  that  can  be  shov/n  to  be  correct. 

”  These  three  principles  are  central  to  the 
understanding  of  the  deficiencies  of  present  systems  and 
provide  a  basis  for  critical  examination  of  protection 
mechanisms  and  a  method  for  insuring  a  system  is  secure. 
It  Is  our  firm  belief  that  by  applying  these  principles  we 
can  have  secure  shared  systems  In  the  next  few  years. 


Deficiencies  at  Enassnl  S.y,S.tflf1S 

c--  Most  current  computer  systems  exhibit  a  complex/  ad 
hoc  security  design  with  diffuse  Implementation  that 
violates  our  third  principle  of  slmol Icl tv.  Large 
portions  of  complex  operating  systems  execute  in  an 
all-powerful  supervisor  state/  so  that  the  entire 
operating  system  has  potential  security  Implications. 
Whatever  nominal  security  controls  exist  In  such  bug-prone 
monoliths  are  not  effective!'*  isolated  (In  violation  of 
our  Isolation  principle)  and  so  can  be  tampered  with 
through  errors  or  trap  doors  In  other  parts  of  the 
operating  system. 

The  significance  of  these  inherent  security  weakness 
has  been  amply  and  repeatedly  demonstrated  by  the  ease 
with  which  contemporary  systems  (such  as  OS/360  and  GCOS) 
have  been  penetrated.  Unfortunately/  this  lack  of  an 
underlying  design  methodology  cannot  be  effectively 
overcome  by  ad  hoc  "fixes"  and  "security  features"  built 
on  an  uncertain  foundation. 

Certification 

A  naive  (but  occasionally  attempted)  approach  to 
Insuring  the  security  of  a  complex  operating  system  is  to 
have  a  penetration  team  of  "experts"  test  the  system.  It 
Is  supposed  that  repeatedly  unsuccessful  penetration 
attempts  demonstrate  the  absense  of  security  "holes". 
Such  a  test  approach  Is  primarily  limited  to  penetration 
attacks  In  areas  indicated  by  the  particular  background 
and  experience  of  the  Individuals  Involved.  A  security 
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evaluation  through  such  attempts  may  reveal  weaknesses  of 
^  "system  but  provide  no  Indication  of  the  presence  or 
'absence  of  trap  doors  or  errors  tn  areas  unnoticed  by  the 
'  attack  team.  The  failure,  of  an  attack  team  to  notice  a 
'  particular  penetration  route  does  not  prove  or  certify 
that  an  actual  penetration  attempt  will  overlook  It  at  a 
later  date.  The  underlying  concern  Is  that  an  active 
:  hostile  penetrator  Is  not  particularly  thwarted  by  the 
_ various  flaws  found  and  fixed  through  testing  so  long  as 
there  remains  Just  one  vulnerability  that  he  can  find  and 
.effectively  exploit. 

On  the  other  hand  our  three  principles  lead  to  a 
simple,  well-defined  subset  of  the  system-  totally 
—  responsible  for  Information  protection.  We  expect  that 
the  primitive  functions  of  this  small,  simple  kernel  can 
be  tested  by  enumeration,  and  other  parts  of  the  system 
are  not  relevant  to  security.  As  a  result  most  system 
.changes  will  not  affect  the  kernel,  so  routine  system 
maintenance  will  not  require  repeated  recertification. 


:  Practical  Mechanisms 

An  abstract  security  model  Is  needed  In  order  to 
evaluate  the  adequacy  of  protection  mechanisms.  Lampson's 
capability  (l.e.,  access  matrix)  model  has  proven  a  useful 
departure  point,  and  we  have  applied  two  design  techniques 
for  developing  a  specific  secure  design: 

a.  The  model  is  represented  in  various  levels  of 

abstraction.  The  design  process  transforms  an  Initial 
abstract  model  of  all  the  system's  protection 

relationships  (derived  directly  from  the  system's  specific 
definitions  of  security,  thus  leading  to  a  model  that  Is 

secure  by  hypothesis)  Into  subsidiary  levels  of 

abstraction.  As  the  design  progresses  from  level  to  level 
the  representations  of  the  model  become  more  specific  and 

-culminate  in  specific  hardware  features.  The  Inter-level 
transformations,  chosen  for  reasons  of  efficiency  as  well 
as  utility,  can  ultimately  be  Implemented  as  primitive 
operations  of  the  kernel,  and  since  the  Inter-level 
transformations  preserve  the  Initial  protection 

relationships,  we  can  prove  that  the  resulting  design  Is 
secure. 

b.  The  kernel  design  is  simplified  by  including  only 
those  relevant  operations  that  modify  access  control  data 
bases,  but  not  those  that  merely  read  this  control 


Information  that  Is  not  Itself  being  pr< 
disclosure.  Consider  as  an  example  a 
system.  At  some  level  of  abstrrtotlon  page 


being  protected  against 


demand 

table 


paging 

entries 


- t.iTITI-  lull  i:c,on  Page  table  entries 

represent  capab  Itles  that  muut  be  carefully  controlled, 
so  the  kernel  will  have  a  Prlm|t!ve  for  chaneln<r  Dace 

aleorl thm* should  not^be^n  the  ,,age  reP1acement  selection 
3 1 1 nm  snou Id  not  D6  In  th6  Security  ko rno  1  • 

nUwing  i  mode1,  ^o^crlptor-based  addressing 

available  In  advanced  processor  hardware  Is  seen  to  offer 
a.  most  promising  basis  for  a  seMlrIty  kernel  deslgn.  In 

tthUS.d3Je“lnrhard2r4,,;.lu"; ,p,e  WlltlW. 

this  a  pressing  naraware  va  iOdi,,s  eacb  memory  reference 

hy  ?#tUjer  s  ?h°CeSS! it  1 jhtorapejs  Che  required  access, 
specified  In  the  applicable  descriptor.  The  security 
kernel  Insures  socurlty  through  ,ts  primitive  operations, 
which  are  Invoked  by  the  remaln.l,lr  of  the  operat?n  s ysteA 
to  malnta  n  the  descriptors.  0„,;ause  a(;cess  con?rJ  ls 

vested  In  the  wel 1 -def Ino.l  and  bounded  descriptor 
mechanism,  kernel  software  funci  |ons  ara  feK  enou|,h  Pand 
simp  e  enough  to  make  certlf  cai ,on  tractabIe,  as  ;equ,rad 
by  simplicity,  our  third  design  principle. 

Descriptor-based  Isolation  mechanisms  (such  as 
Schroeder’s  hardware  Implemented  rPnes  for  Multlcs)  can 
provide  effective  as  well  as  eff|c|ent  protection  of  the 
security  kernel.  Thus,  as  lmpltnd  by  our  second  design 
principle  (JUnialXfill) ,  an  antngon|st  could  have  complete 
freedom  within  the  remainder  of  the  systam  „ithout 
compromising  the  protection  Prov|ded> 


prospect  tsiL  Xh&.  Ey&UJlfi 

^orce  a*!e  Plir,JuIng  a  development  effort 
for  providing  secure  shared  sy5.nms  ,n  the  next  few  years. 

In  cooperation  with  the  MITRE  Corporation,  we  are  already 
applying  our  three  design  principles  to  shared 
communications  processors  In  ifoe  laboratory,  and  tve  have 
begun  to  extend  these  Ideas  to  n  deS|gn  for  a  shared/ 
general  purpose  computer  system, 

We  are  confident  that  from  the  standpoint  of 
technology  there  Is  a  good  < hance  for  secure  shared 
systems  In  the  next  few  years,  However,  from  a  practical 
standpoint  the  secur  ty  problem  wm  remaIn  as  lo  as 
manufacturers  remain  commit  i*d  to  current  system 
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architectures/  produced  without  a  firm  requirement  for 
"security.  As  long  as  there  Is  support  for  ad  hoc  fixes 
and  security  packages  for  these  Inadequate  designs/  and  as 
:tong  as  the  Illusory  results  of  penetration  teams  are 
.accepted  as  a  demonstration  of  computer  system  security/ 
'proper  security  will  not  be  a  reality.  . 


ON  THE  DESIGN  OF  SECURE  SYSTEMS 


i  i.  h  - 

SECTION  1  PHILOSOPHY 

v-  «  - 

-'Our  Intent  Is  to  provide  a  basis  for  the  design  of 
multiuser  computer  systems  In  which  there  exist  security 
mechanisms  that  provide:  1)  a  useful  degree  of  flexible 
security  and  2)  a  high  degree  of  confidence  in  the 
integrity  of  the  mechanisms. 

The  problem  of  computer  security  Is  well  recognized 
and  a  number  of  systems  and  system  designs  have  been 
proposed.  However,  It  Is  often  difficult  to  evaluate 
these  efforts  without  understanding  the  assumptions 
Implicit  in  the  system  design  or  recognizing  what  portion 
of  the  security  problem  the  system  purports  to  solve. 

Hence,  we  briefly  state  In  general  terms  our 
conception  of  that  part  of  the  current  military  computer 
security  problem  that  we  will  consider,  and  later  restate 
this  general  conception  more  exactly.  The  kind  of 
security  that  is  currently  desired  Is  not  complex  In  Its 
functional  capability.  We  do  not  demand  the  ability  to 
handle  the  problems  of  aggregation.  Inference,  or  mutually 
suspicious  subsystems.  Vie  do  not  attack  those  problems 
which  seem  to  require  a  monitoring  and  general 
understanding  of  the  use  to  which  Information  will  be  put, 
excepting  rather  simplistic  controls  like  read,  write  and 
execute,  and  hence  are  satisfied  by  a  set  of  simple 
decision  rules  which  operate  on  Information  recorded  In 
the  system,  not  unlike  the  class  of  facilities  that  a 
number  of  timesharing  systems  provide  today. 

The  critical  requirement  Is  extremely  high  Integrity: 
great  confidence  that  the  specified  design  of  the  security 
facilities  of  the  system  are  in  fact  guaranteed.  We 
recognize,  of  course,  that  the  system  must  provide  useful 
capabilities,  since  otherwise  a  guaranteed  design  or 
Implementation  Is  vacuous.  That  is,  the  proposed  security 
controls  must  allow  the  Implementation  of  a  multiuser 
computer  system  with  functional  capabilities  not  unlike  a 
number  of  today's  common  commercially  available  time 
sharing  systems. 


k 


In  an  attempt  to  fulfill  these  goals,  the  following 
strategy  is  proposed:  develop  a  simple  logical  design 
whose  correctness  can  be  verified,  and  whose  elements  are 
both  simple  enoug h  and  close  enough  to  real  system 
features  so  that  Implementation  of  the  model  is  reasonably 
straightforward. 

As  the  abstract  model  Is  developed,  we  shall  be  guided 
by  the  Idea  of  a  kernel .  We  thtend  to  isolate  that 
portion  of  the  system  responsible  for  security  and  place 
It  In  a  protected  part  of  the  system,  in  a  manner 
analogous  to  the  way  In  which  current  supervisors  are 
segregated  from  user  programs,  it  will  be  necessary  to 
demonstrate  that  this  segregation  is  performed  In  a- way 
that  guarantees  the  kernel's  Integrity  and  also  guarantees 
that  the  kernel  Is  always  Invoked  to  arbitrate  attempted 
references.  These  tasks  are  eased  by  the  fact  that  we 
will  design  our  security  model  so  that  It  can  aid  In 
protecting  Itself. 

By  segregating  the  responstbll Ity  for  security,  the 
problem  of  verifying  the  system's  security  mechanisms 
becomes  that  of:  1)  demonstrating  that  the  kernel  is 
always  invoked,  and  2)  verifying  that  the  kernel  operates 
properly.  The  problem  has  been  greatly  reduced  from  that 
of  verifying  properties  of  an  entire  operating  system  to 
that  of  verifying  a  (presumably)  small  portion  of  It. 

The  design  model  should  consist  of  several  levels  of 
abstraction.  The  top  level  is  a  logical  description  of 
security  systems;  the  lowest  level  closer  to  a  possible 
machine  Implementation.  Higher  levels  are  more  machine 
Independent  than  lower  levels.  The  intent  is  to  prove  the 
correctness  of  an  upper  level  machine  independent  model, 
and  demonstrate  that  translations  to  lower,  more  specific 
levels  preserve  the  relevant  properties  of  the  top  level. 
Through  the  use  of  this  top  down  Informal  structure,  we 
hope  to  demonstrate  the  correctness  of  an  implementable 
design  for  a  secure  system.  Lest  readers  labor  under  any 
misconceptions,  it  should  be  pointed  out  that  while  the 
"proof"  structure  is  top  down,  the  system  design  certainly 
Is  not.  Fairly  well  defined  Ideas  of  the  desired  end 
product  exist.  The  top  down  approach  Is  primarily  for 
purposes  of  description  and  proof. 

A  remark  should  be  made  concerning  the  meaning  of 
"correctness",  and  "proofs  of  correctness".  A  system 


11-2 


cannot.  In  a  vacuum,  be  proved  correct.  It  may,  however, 
be  possible  to  demonstrate  that  a  system  design  agrees 
with,  or  fulfills,  certain  external  criteria,  that  is, 
conditions  which  are  not  explicitly  part  of  the  design. 
These  external  criteria  specifically  characterize  that 
"computer  security  problem"  which  we  consider. 

We  will  demonstrate  that  in  certain  cases  these 
explicit,  external  criteria  can  be  made  part  of  the  system 
design.  In  such  a  manner  that  they  are  always  applied, 
reducing  the  problem  of  an  informal  correctness  proof. 


A  last  constraint  Is  placed  on  the  design  by.the'need 
for  efficiency.  The  security  mechanisms  should  not 
markedly  degrade  the  price/performance  characteristics  of 
a  system.  The  effect  of  this  constraint  Is  more  apparent 
as  discussion  moves  closer  to  implementation. 
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SECTION  2  -  A  SECURITY  META-MODEL 


Introduction 

The  following  approach  Is  Intended  as  a  guide  for  the 
logical  design  of  computer  security  systems.  The 
description  applies  to  a  wide  class  of  security  systems. 
Including  most  of  those  In  practice  or  proposed  today. 

Naturally,  then,  the  meta-model  does  not  provide  an 
Instance,  or  Implementation,  of  a  useful  secure  system. 
Using  the  meta-model,  for  example,  one  can  provide 
Inappropriate  standards  for  correctness,  or  one  can  design 
a*  system  that  Is  not  useful.  As  a  case  in  point,  whether 
or  not  provision  is  made  for  the  operation  of 
"cooperating,  mutually  suspicious  process".  Is  Irrelevant 
to  the  meta-model. 

However,  the  security  meta-model  allows  one  to  relate 
various  specific  models,  and  provides  a  specific  guide  to 
those  actions  necessary  to  guarantee  the  correctness  of  a 
security  design. 


Nomlon 

In  the  following  discussion,  some  non-standard 
notation  Is  used  to  linearize  formats.  Several 
conventions  should  be  pointed  out.  Subscripts  are 
enclosed  In  square  brackets.  Sets  are  labelled  by  capital 
letters,  and  elements  of  that  set  are  generally  labelled 
by  the  same  letter,  but  in  lower  case  and  subscripted. 
Hence  aCjJ  refers  to  the  j-th  element  of  the  set  A. 

It  Is  occasionally  necessary  to  speak  of  the  names  of 
members  of  a  set,  rather  than  the  members  themselves.  The 
set  of  names  which  corresponds  to  a  set  of  elements  Is 
denoted  by  an  underline.  So,  for  example,  the  set  A#  with 
elements  aCJ3  is  a  set  whose  elements  are  names, 
corresponding  to  the  set  A. 

Last,  the  power  set  of  a  set  X  Is  written  P(X>. 
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Brief  Description 

The  model  Is  described  In  set  theoretic  language,  and 
J»as  six  major  components.  First  Is  the  set  0  of  security 
Ahi  ects:  the  elements  of  the  model,  reflecting  those 
physical  or  logical  parts  of  a  computer  system  that  need 
to  be  controlled,  protected,  or  whose  status  needs  to  be 
^guaranteed.  The  objects  are  partitioned  Into  disjoint 
classes,  each  containing  objects  of  similar 
characteristics.  An  Incomplete  list  of  examples  Includes 
terminals,  communication  lines,  processes  and  files. 

Second,  a  set  A  of  access  types  Is  presented.  ,  Each 
access  type  is  a  program  which  effects  a  particular 
variety  of  access,  such  as  read,  write,  or  execute.  An 
^attempted  access  operation  is  then  completely  specified  by 
an  access  type  and  some  meaningful  collection  of  objects, 
tl.e.  a  particular  process  being  directed  from  a  given 
terminal  attempting  to  reference  a  specified  page  In 
memory. 

Third,  a  collection  of  descriptive  data  DCkj,  from 
.the  set  of  all  possible  desct Iptlve  data  collections  D  Is 
required.  DCkj  specifies  the  Information  that  forms  the 
basis  by  which  security  decisions  will  be  made.  The 
subscript  k  indicates  a  time  dependency. 

Fourth,  an  evaluation  program.  E  decides,  for  any 
meaningful  grouping  of  objects,  what  operators  are  to  be 
allowed. 

Fifth,  an  update  program  V  is  characterized 
separately.  This  program  Is  the  means  by  which  the 
-descriptive  data  are  changed.  Operationally,  this  Is  the 
manner  by  which  access  decisions  may  be  altered. 

In  many  real  Implementations,  the  distinction  between 
the  evaluation  program  and  update  program  may  not  be 
clearcut,  since  the  descriptive  data  Is  likely  to  be 
•stored  and  protected  like  any  other  security  object.  Both 
.-programs  are  treated  here  so  that  their  similar  nature  Is 
apparent.  Nevertheless,  the  distinction  will  be  useful 
since  Implementations  of  the  two  programs  may  differ.  E, 
while  likely  to  be  software  Implemented,  calls  upon  access 
programs  to  do  its  actual  work,  and  these  may  be  at  least 
partly  If  not  wholly  built  in  hardware.  |5  on  the  other 
hand  In  many  cases  will  be  almost  exclusively  software  and 
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actually  changes  the  formatted  descriptive  data. 


Last,  external  correctness  criteria  are  required. 
These  are  a  set  of  rules,  or  standards  T,  by  which  the 
system  Is  to  be  adjudged  correct.  These  standards  must  be 
external  to  the  system  description  up  to  this  point  In 
order  to  be  meaningful . 

A  security  system  S  Is  then  specified  by  the 
slgrtuple: 

■  (0,  A,  0,  E,  0,  T). 


Ihs.  Components  At  lh&  Model 


Security  QhiAfcta 

The  first  component  of  the  model,  the  security 
objects.  Is  a  finite  set  0: 

0  -CoriJ.  of2j,  ...,  o [zJJ. 

These  are  the  only  objects  to  which  access  will  be 
controlled  by  the  model,  and  by  a  resulting 
Implementation. 

J 

I 

Accssa  Iyp.fiA 

The  second  component  of  the  model  Is  a  set  of  access 
types: 

A  -  f  afc>3,  aflj,  a [2],  ...,  afwJJ 

Each  aflj  Is  a  program  whose  effect  will  be  to  provide  a 
particular  variety  of  access,  read,  write,  or  execute  for 
example.  The  list  of  arguments  for  each  a£l3  must  be 
finite  and  contain  names  of  security  objects.  In 
addition,  a£oJ  Is  designated  as  the  nut  1  access  program. 
This  program  will  be  Invoked  when  access  Is  to  be  denied. 
It'  can  keep  audit  trails,  set  up  warnings  to 
administrators,  etc. 
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acDescr 1 pt I ve  Data 


The  third  component/  the  descriptive  data/  Is  merely 
a  set  of  tuples: 

D[kJ  ■  f  dfk,l],  d [k#2] ,  ...#  d[k,vj|, 

c  -with  some  finite  upper  bound  set  on  v.  We  depart  somewhat 
from  our  strict  set  theoretic  notation  by  speaking  of  the 
structure  of  a  tuple. 

Each  tuple  Is  only  assumed  to  have  a  bounded  number  of 
entries/  the  first  of  which  acts  as  a  "data  descriptor"  to 

distinguish  among  tuples  of  different  formats  and  content. 

< 

For  example/  one  type  of  tuple  might  be  an  encoding 
_of  a  matrix  entry  In  Lampson’s  model  p4j;  the  entry 
expressing  an  access  relation  between  two  security 
objects.  Another  might  express  a  property:  user  x  belongs 
to  project  y/  or  has  clearance  z.  A  property  may  also  be 
I_va1ld  only  for  several  users  jointly.  Such  circumstances 
do  not  fit  naturally  Into  a  matrix  representat Ion  of  the 
descriptive  data/  so  tuples  are  preferred  here. 

Explicit  use  of  the  structure  of  the  descriptive  data 
will  not  be  made  In  the  following  discussion  of 
correctness/  although  It  Is  necessary  In  the  more  detailed 
proof.  The  finiteness  of  both  the  length  and  number  of 
:  tuples  will  be  useful  here/  however. 

Let  X*  be  the  set  of  all  allowed  tuples/  and  D  ■ 
P(X*)  the  power  set  of  X*.  Then  Dfk3  Is  some  member  of 
P(X*>. 

■  fctal.viflU.an  Ecafliam 

The  third  portion  of  the  model  is  an  evaluation 
program  E  which  uses  descriptive  data  to  make  decisions 
:  concerning  access.  For  any  evaluation  program/  the  list 
of  arguments  Is  composed  of  some  fixed  number  of  objects 
from  each  partition  of  the  security  objects  0/  and  an 
'  access  type;  the  name  of  an  element  In  A.  For 

convenience/  those  objects  are  denoted  by  6. 

The  task  of  the  evaluation  program  Is  to  decide 
whether  or  not  the  specified  objects  may  be  associated  In 
the  manner  expressed  by  the  access  type  and  to  Indicate  an 


appropriate  action.  That  Indication  Is  done  by  selecting 
the  appropriate  access  program  and  specifying  Its  proper 
arguments. 

The  evaluation  program  E  takes  a  list  of  object 
names,  a  particular  descriptive  data  configuration,  and 
the  name  Of  an  access  type  (names  of  elements  are 
underlined);  and  returns  the  allowed  access  program 
together  with  the  argument  list  for  that  access  program. 

.  E  Is  composed  from  an  access  rule  E.  E  Is  a  fairly 
arbitrary  program  that  is  assumed  only  to  1)  terminate, 
returning  true  or  false,  and  2)  be  read  only. 

The  Intent  Is  that  E  describe  conditions  to  be 
fulfilled  In  order  to  allow  access.  It  may  be  an 
arbitrary  function  of  its  arguments,  although  often  such 
programs  are  fairly  simple. 

Then  the  program  E  may  be  written  as  follows: 

E  i  proc  (6,  Dfk],  A[jl)  returns  list; 

lock;  , 

it  E(0,  D[kJ,  aCJ]) 

then  begin  unlock;  call  aC'.JO)  end: 

else  begin  unlock;  call  aC>J(6>  end: 

end; 

The  list  which  Is  returned  specifies  an  access  type 
and  the  argument  list  for  that  program.  The  arguments  for 
E  are  the  same  as  for  E  Itself. 

The  functions  lock  and  unlock  are  understood  to  act 
on  a  single  semaphore,  as  D! jkstra's  operators  P(x),  V(x). 
It  Is  necessary  to  coordinate  the  operation  of  E  and  |5  so 
that  E  is  not  reading  D£kJ  while  15  Is  updating  Dfkj. 
Otherwise,  It  would  not  be  possible  to  prove  that  E  and  |t 
perform  In  all  cases  as  claimed. 

UfiAutfi  Program 

The  update  program  is  the  means  by  which  descriptive 
data  Is  changed.  Hence  It  Is  the  manner  by  which 
decisions  that  the  evaluate  program  makes  can  be  affected. 
Let  9*  denote  the  set  of  arguments  for  the  update  program 
which  are  security  objects,  D£yJ  Is  the  current 
descriptive  data,  and  DfzJ  Is  the  data  to  which  It  Is 


.  desired  to  change.  0  yields  either  the  original  data, 
!  prohibiting  the  change,  or  the  new  data,  having  allowed 
.  .the  change . 

•The  update  program,  too,  is  composed  from  some 
..effective  procedure  U,  similar  In  purpose  to  E,  and  so  the 
update  program  0  may  be  written  as: 

U  :  oroc  (0’,  Dfyj,  Dfzj)  returns  element  of  D; 
lock; 

•  JLf  U(0* ,  DCyJ,  0 CzJ) 

than  begin  unlock:  return  D  (zj  end 
else  begin  unlock;  return  DfyJ  end 

find; 

The  arguments  for  U  are  the  same  as  for  the  procedure 
Itself. 

.  Correctness  Cl.Ucrl  0 

The  security  objectives  of  the  access  control  system 
are  the  qualities  that  it  Is  necessary  to  guarantee.  For 
a  certain  well  defined  class  of  criteria,  there  Is  a 
straightforward  method  of  taking  a  logical  description  of 
a  security  system  and  altering  that  model  to  provide  a 
derived  system  model  In  which  the  given  correctness 
criteria  hold. 

The  correctness  criteria  are  expressed  as  a  set  T  of 
predicates: 

T  ■  (tCll,  t  [2],  ...,  t  [q]  3 . 

These  are  the  predicates  that  must  be  proven  true  for  the 
system. 

In  this  model,  predicates  may  be  expressed  In  one'  of 
two  forms,  and  so  T  Is  partitioned  Into  two  subsets  T1  and 
T2  corresponding  to  the  two  alternatives. 

If  tClJ  Is  In  T1  then  it  may  be  any  predicate 
expressible  in  the  following  functional  form: 

tflj  :  0  x  D  x  A  “>  ft  rue,  false?. 

The  Interpretation  of  predicates  In  T1  Is  that  the  object 
list  from  6  may  be  associated  with  access  type  aCjl  in  A 
and  a  given  D£k]  In  0  onl:v  If  t;  Cl J  Is.  true. 
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If  tflj  Is  In  T2,  then  It  may  be  any  predicate 
expressible  In  the  following  functional  form: 

tCIl  :  9'  x  DCj  J  x  DCkJ  ->  ft  rue,  false? 

The  Interpretation  Is  that  the  descriptive  data  0 CjJ  may 
be  changed  to  D£kJ  by  the  objects  expressed  by  0'  only  If 
t£l3  Is  true. 

Let 

71  -  And  (tCU)  for  all  t£IJ  In  T1  and 


let 

'  72  -  And  (tfjJ)  for  all  tfj]  In  T2. 

71  and  72  take  the  same  arguments  as  the  t£IJ  and  t£j], 
respectively. 

-  '  To  demonstrate  that  a  system  Is  correct/  It  Is 
necessary  to  guarantee  the  truth  of  71  and  72.  Below,  a 
simple  way  Is  shown  to  take  any  security  system  S  and 
derive  from  It  a  system  S'  for  which  the  given  71  and  72 
are  true. 


Deni.vatlgn  si  Carr-fitt  &xajLfim 


System  Saccl.f  Icatlan 

As  described,  a  security  system  S  Is  a  tuple: 

S  -  (0,  A,  DCo3,  I,  0,  T) 

0  Is  the  object  set,  A  Is  the  set  of  access  types,  DCo3  Is 
taken  as  the  set  of  tuples  which  comprise  the  Initial 
descriptive  data,  E  Is  the  evaluation  program,  0  Is  the 
update  program,  and  T  is  the  set  of  predicates  to  be 
guaranteed.  t 

For  a  particular  system  S,  the  entries  A,  E,  0,  and  T 
are  fixed.  The  descriptive  data  DCkl  may  be  varied  by  use 
of  0.  Then  the  state  of  a  security  system  S  can  be 
completely  expressed  by  Its  descriptive  data  D£k3,  for 
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some  k.  The  update  program  Is  the  means  by  wfitch  a  system 
S  may  change  states  and  the  compound  .'predicate  c72 
expresses  the  constraints  on  allowed  state  changes.  The 
evaluation  program  E  "Interprets"  a  particular  state,  and 
71  expresses  the  constraints  on  E. 

Given  a  security  system  S  ■  (0,  A,  D£o},  E,  If,  T) , 
system  S'  ■  (0,  A,  D(o],  V ,  14',  T)  Is  produced  by  the 
following  Inclusion  step. 

**  • 

I1  Is  derived  from  E  by  the  following  change. 
Replace  "E(...>"  by  "E(...)  and  71(6,  D,  a£j3>". 

II'  Is  derived  from  (4  by  the  following  change: 

Replace  "U(...)"  by  "U(...)  and  72(6',  DCyJ,  D£zJ)".  - 


Correctness  Proof 

First  It  Is  helpful  to  define  a  few  terms. 

A  state  DCn]  of  a  system 

S  -  (0,  A,  DCoJ,  E,  H,  T) 

Is  val Id  if  and  only  If  D£nJ  can  be  obtained  from  D£oJ  by 
a  finite  number  of  applications  of  I 4  and,  for  each  such 
transition  from  state  OCkJ  to  DCk+13, 

T2C.6* ,  OCkJ,  D£k+13)  - 

for  some  0' . 

Second,  a  state  DCk]  Is  accurately  Interpreted  if  and 
only  If  for  any  6  and  any  j: 

14(0',  D£k3,  DCj3)  ■  (0',  a£oJ)  whenever 
71(6,  D[kJ,  a[jj)  ■  falsa  (where  aCoJ  Is  the  null  access 
type). 

Then  to  say  that  a  system  S  Is  correct  Is  meant  the 
following: 

1)  Every  state  obtainable  from  DCol  Is  valid,  and 

2)  Every  valid  state  Is  accurately  Interpreted. 


i 
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We  now  state  the  following  (system  correctness) 

theorem; 

Given  a  security  system 

S  -  (0,  A,  DCoJ,  T)  with  T  partitioned 

Into  T1  and  T2;  } 

mil  S'  -  (0,  A,  DCo3,  V ,  H',  T)  derived  from  S 

% 

by  the  Inclusion  step 
■LilfiQ  1'  JL&  correct. 


£rofii  SKfitch 

An  easy  way  to  prove  the  theorem  Is  by  contradiction. 
Suppose  the  theorem  false.  Then,  by  definition  of 
correct.  S'  reaches  an  Invalid  state,  or  a  valid  state  Is 
Inaccurately  Interpreted. 

•  T 

Case  1;  Assume  an  invalid  ;tate.  Label  that  Invalid 
state  D£kJ.  Then  there  must  exist  a  sequence  of  states 
Dfo3,  DflJ,  Df2J,  ...,  Ofk]  such  that  H  (8CU,  D CU, 
DCI+13)  -  OCI+13  for  all  l<k,  since  )9  makes  the  transition 
from  state  to  state. 

Now  DCol  Is  valid  by  definition.  DCk]  Is  Invalid  by 
assumption.  Then  there  must  exist  a  non-negative  Interger 
j,  less  than  k,  such  that  QCjJ  Is  valid  and  DQ+13)  Is 
Invalid.  Hence,  by  definition  of  valid,  72(8,  DCjJ, 
Olj^lJ)  Is  false.  But  #(8,  DE33,  DCj+l3)  -  DQ+13.  By 
Inspection  of  |4,  these  two  conditions  cannot  hold,  and 
hence  a  contradiction  is  reached. 

Case  2;  Assume  an  inaccurately  interpreted  valid 
state.  Call  that  valid  state  OCkJ.  Then  by  definition  of 
an  accurate  Interpretation,  for  some  8C13  and  afjj,  the 
following  Is  true. 


71(8113,  D£k3,  aljj)  -  false  and 
t  (8  Cl]  ,  DCk] ,  aCJ3>  t  (8,  a£o]> 
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By  Inspection  of  this  Is  a  contradiction.  Hence  every 
valid  state  Is  accurately  Interpreted. 

Both  cases  are  Impossible.  Hence  the  theorem  cannot 
be  false. 

qed 


This  proof  Is  of  course  nearly  tautologtc  In  nature. 
Discussion 

This  security  meta-model  and  the  Inclusion  technique 
are  Intended  as  an  aid  In  the  design  of  secure  multiuser 
computer  systems..  Hence  some  of  the  assumptions  and 
Implications  Inherent  In  the  chotce  of  language>  model, 
and  technique  ought  be  made  expllctt. 

The  primary  Influence  In  this  meta  model  was  the 
realization  that  Its  value  Is  solely  In  Its  ability  to  aid 
the  Implementation  of  a  demonstrably  secure  system.  Hence 
.the  model  and  Its  elements  must  conform  to  the  modules  and 
capabilities  of  computer  systems  not  unlike  those  In 
existence  today.  At  the  same  time,  a  simplicity  and 
coherence  was  desired,  reasonably  free  of  Implementation 
questions,  that  would  provide  some  understanding  of  the 
contemporary  security  problem.  It  Is  felt  that  the  basic 
concepts  explicated  here  are  a  reasonable  start  toward 
these  goals,  although  It  is  freely  admitted  that 
exposition,  notation  and  other  details  may  require 
Improvement. 


A  number  of  implementation  Implications  of  this  meta 
model  can  be  mentioned. 


First,  It  should  be  pointed  out  that  effective 
procedures  exist  for  the  update  and  evaluation  programs, 
the  predicates  from  which  they  are  composed,  and  the 
predicates  which  make  up  the  correctness  criteria.  This 
fact  Is  a  result  of  the  flntteness  of  all  the  sets 
Involved  In  the  meta-model.  That  effective  procedures 
exist  for  all  the  predicates  in  the  theorem  set  T  makes 
the  Inclusion  technique  actually  useful.  In  certain 
actual  Implementations  of  course.  It  may  be  possible  to 
demonstrate  the  truth  of  some  of  the  correctness  criteria 
without  dynamically  verifying  them  at  run  time. 
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,  No  claim  of  efficiency  Is  made  In  this  model/  since 
for  any  particular  system  the  predicates  may  be  complex 
and  the  descriptive  data  specified  in  a  manner  that 
requires  a  great  deal  of  work  to  check  the  given 
predicates.  On  the  other  hand/  as  will  be  demonstrated  in 
a  companion  paper/  the  correctness  criteria  predicates  for 
certain  real  problems  are  rather  simple/  and  careful 
design  of  the  descriptive  data  can  greatly  aid  efficiency 
while  remaining  faithful  to  this  meta-model.  It  Is  this 
fact  which  really  guarantees  the  effectiveness  of  the 
Inclusion  step. 


....  The  next  abstract  level  is  sketched  In  a  companion 
paper  in  order  to  demonstrate  that  a  useful  security 
system  can  be  described  with  the  language  of  the 
meta-model/  showing  that  the  meta-model  ts  not  vacuous. 


UL  1&  Intended  that  the  kernel  of  a  computer  system 
Include  everything  JLhit  this  meta  mad  el  contains/  and 
nothing  else.  Hence  the  meta  model  defines  the  boundaries 
of  the  kernel/  and  the  ability  to  use  the  kernel  to 
protect  parts  of  Itself  will  allow  one  to  provide 
carefully  controlled  access  to  the  kernel  Itself. 


Summao 


The  meta  model  provides  a  language  for  describing  a 
useful  class  of  security  systems,  it  easily  lends  Itself 
to  the  use  of  a  technique  which  guarantees  that  the 
objectives  of  the  system  are  fulfilled  by  the  model.  The 
concepts  of  the  model  are  relatively  simple  and  bear  a 
reasonably  close  relation  to  the  kinds  of  computer  systems 
In  existence  today/  suggesting  the  possibility  of 
providing/  with  high  confidence/  a  faithful  implementation 
of  the  model.  An  accurate  implementation  of  a  desired 
security  design  is,  after  all/  the  primary  goal  of  all  of 
this  work. 
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MUSINGS  CONCERNING  A  SPECIFIC  SECURITY  MODEL 


(The  following  thoughts  were  sketched  under 
significant  time  constraints  and  are  released  In  their 
present  form  only  with  considerable  reluctence. 
Nevertheless,  It  Is  hoped  that  a  useful  partial 
explication  Is  provided  of  the  applicability  of  the  ideas 
previously  presented,  specifically  the  kernel  and  the  meta 
model  design  approach.) 


With  the  general  outline  of  the  security  meta-model 
In  mind,  we  sketch  a  model  of  a  particular  security 
system.  It  Is  not  an  extremely  general  one,  but  rather  Is 
Intended  as  a  statement  of  current  military  needs  In  a 
context  that  both  provides  a  basis  for  a  proof  of 
correctness  and  can  lead  fairly  directly  to  an 
implementation.  To  make  It  clear  that  Implementation  Is 
possible,  the  flavor  of  the  structure  Is  taken  from  the 
existing  file  system  of  Multlcs. 

A  few  notes  should  be  made  concerning  the  intended 
environment  of  this  model.  An  on  line  multiuser  computer 
Installation  Is  expected,  where  the  mechanisms  proposed  in 
this  model,  directly  or  Indirectly,  check  every  reference 
made  to  information  contained  in  the  system. 

The  QteistLa. 

The  object  set  0  might  be  partitioned  Into  four 
subsets: 

Ot  ■  a  set  of  terminals 
Ou  ■  set  of  users 
Od  ■  set  of  data  objects 
Os  •  set  of  security  objects 

Terminals  are  meant  to  be  representative  of  the  entire 
class  of  I/O  devices,  and  could  Include  teletypes, 
printers,  tape  drives  and  the  like.  For  every  user 
recognized  by  the  system,  there  Is  an  object  In  Ou;  the 


"user  process".  Oata  objects  include  both  executable  and 
non-executable  objects;  the  Items  that  the  system  Is 
Intended  to  protect.  Lastly  there  are  security  objects. 
Security  objects  contain  the  information  upon  which 
security  decisions  will  be  made.  There  are  two 
distinctions  between  data  objects  and  security  objects. 
First#  security  objects  will  have  a  rigidly  enforced 
Internal  structure  necessary  for  proper  operation  of  the 
security  system#  while  data  objects  are  format  free  - 
completely  free  form  Internally.  Second,  security  objects 
will  be  accessed  directly  only  by  the  decision  and  update 
procrams . 

Names  of  objects  will  be  required  distinct#  of 
course. 


As  already  mentioned#  the  descriptive  data  Is 
contained  In  the  security  objects.  This  containment 
provides  a  manner  by  which  access  to  the  descriptive  data 
Itself  can  be  controlled  by  the  mechanisms  of  the  model. 

Any  security  object  os(l)  Is  an  ordered  list  of 
descriptors 

os ( I )  *  *d(l)#  d<2>#  ...  d(n)J 
where  a  descriptor  Is  an  n-tuple#  and  ni.5 
-  d(l)  »  Cfl,  o#  Si*  R*  r(l)#  r(2)#  ...#  r(k)3 

In  any  descriptor#  £  ts  the  name  of  a  member  of  the 
object  set  0. 

The  second  element#  m  is  a  member  of  the  mode  set  M. 

M  -£l#  2#  3#  4#  5#  6#  7J 
The  compartment  list  is  the  third  entry. 

It  Is  useful  to  be  able  to  label  an  object  as  a 
member  of  any  number  of  several  areas#  or  compartments. 
Hence  a  set  of  compartments  is  defined: 
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£e.  ......  c'  •  £c<l),  c<2>,  ...,  cU7)3 

and  for  convenience  we  also  define 

c  ■  P(c)  ,  the  power  set  of  c*. 

~~  Any  compartment  list  Is  the  name  of  an  element  In  C. 

■  .  ,  n 

The  remaining  entries  except  for  P  are  relations; 

—  there  will  be  an  arbitrary  number  of  them.  To  describe 

.  relations,  define  first  the  access  type  set  A'. 

A'  ■  [copy,  write,  execute,  read,  update? 

—and  also  A  ■  P(A').  * 

_Then  any  relation  Is  a  2-tuple  Cou,  aj  whose  first  entry 
Is  a  user  name:  of  an  object  from  Ou,  and  whose  second 
entry  Is  the  name  of  an  element  of  the  set  A 

Each  member  of  the  access  set  can  be  thought  of  as  a 
-program  whose  effect  Is  to  provide  a  particular  variety  of 
access.  The  necessary  parameters  are  specified  later,  but 
It  Is  assumed  In  this  section  that  these  programs  are 
correct.  What  such  programs  actually  do,  of  course, 

-  provides  the  semantics  for  their  names. 

It  Is  Intended  that  the  access  types  copy,  write,  and 
execute  apply  to  data  objects:  write  and  execute  have  the 
usual  interpretation,  while  copy  Is  synonomous  with  the 
usual  definition  of  read.  Copy  Is  a  better  mneumonic  for 
the  actual  ability  provided.  Read  and  update  are  access 
types  that  refer  to  security  objects,  and  will  have  the 
suspected  meaning.  The  last  entry  In  the  descriptor  not 
yet  mentioned  is  p.  This  entry  Is  a  specification  of  the 
actual,  machine  dependent  location  of  the  object  whose 
name  is  the  first  entry  In  the  descriptor. 

The  format  of  the  security  objects'  Internal 
structure  has  now  been  Informally  defined.  Some  additions 
will  be  required  like  indicators  of  the  number  of 
relations  In  a  descriptor  and  the  number  of  descriptors  In 
a  security  object.  Additional  restrict  ions,  on  the  actual 
content  of  security  objects,  will  be  Imposed  by  Initial 
conditions  and  the  updating  procedures. 
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Before  continuing/  It  may  help  to  discuss  the 
motivation  for  the  format  selected,  and  the  Intended  use 
to  which  the  data  will  be  put  by  the  access  and  update 
programs.  One  will  be  able  to  represent  the  total 
descriptive  data  by  a  tree,  where  the  nodes  are  security 
objects,  and  the  edges  from  father  to  son  are  Indicates  by 
descriptors  whose  mode  entry  is  £,  for  security  object.  A 
tree  link  lies  between  a  security  object  named  by  the 
entry.  Descriptors  with  other  modes  specify  terminal 
leaves:  the  other  objects,  terminals,  users,  and  data  In 
the  model.  This  tree  structure  provides  the  manner  by. 
which  access  to  descriptive  data  can  be  controlled,  since 
each  node  contains  the  information  relevant  to  access 
control  for  each  of  its  sons.  Access  to  the  root  node  Is 
treated  differently  -  It  will  be  free  for  read,  but  not 
possible  to  change. 

The  update  program  will  guarantee  that  the  name 
actually  stored  In  a  descriptor  is  unique:  no  two 
descriptors  will  have  the  same  name  entry. 

The  totality  of  Information  about  objects  that  the 
security  system  will  employ  to  make  access  decisions  Is 
contained  In  the  descriptor. 

The  Evaluate  Program 


The  program  Is  the  manner  by  v/htch  the  descriptive 
data  Is  Interpreted  to  control  access  to  data  objects. 

First,  we  assume  the  existence  and  correctness  of  the 
programs  which  make  up  the  access  set. 

Each  such  procedure  takes  as  arguments  a  user  name,  a 
terminal  name,  and  a  data  object  name.  Its  action  Is  to 
perform  those  hardware  and/or  software  operations 
necessary  for  the  access  to  take  place. 

In  addition,  we  assume  the  existence  of  two  correct 
procedures,  user  and  terminal .  which  return  the  name  of 
the  user  object  which  has  Initiated  the  current  access 
request,  and  the  terminal  from  which  the  request  was 
Initiated,  respectively.  In  addition,  we  assume  the 


existence  of  a  access  type  program,  that  returns  the  kind 
of  access  requested:  the  name  of  an  element  In  A;  and  a 
reference  program  that  returns  the  name  of  the  data  object 
to  be  referenced.  (These  tv/o  programs  need  not  be  proven 
correct.)  We  also  assume  the  existence  of  a  program  null 
which  may  be  a  nop,  but  may  also  Initiate  recording  of 
certain  parameters  for  later  Inspection.  Nul 1  Is  only 
guaranteed  not  to  grant  any  access. 

I 

The  evaluate  program  In  tts  Initial  state  Is 
relatively  simple.  To  keep  questions  of  Implementation 
burled  for  the  moment,  we  assume  the  existence  of  another 
correct  program. 

Relation  (b,  c,  d)  has  arguments  b*data  name,  cuser 
name,  and  d»access  type  name,  the  name  of  a  program  in  A'. 
This  program  returns  true  Iff:  1)  there  exists  a 
descriptor  entry  specified  by  b,  and  2)  there  Is  a 
relation  tuple  Cc,  k3  In  that  descriptor,  where  k 
specifies  a  subset  of  the  access  types  which  Includes  d. 

An  Initial  evaluate  program  might  then  be  written 
following  the  outline  In  the  security  meta  model,  but  with 
relation  (reference,  user,  access-type)  replacing  E  In  the 
evaluate  program  %.  Note  that  while  the  terminal  involved 
In  this  activity  has  not  been  Included  in  the  check.  It 
would  be  a  simple  matter,  given  the  existence  of  the 
routine  iarmlnal . 


The  Update  Program 


To  more  easily  describe  the  update  program  at  this 
level  we  again  assume  the  existence  of  several  programs: 

create  (&,  &&)  creates  the  object  with  name  £ 

and  adds  a  descriptor  In  as,  with  default  sensitivity  and 
compartment  list. 

delete  (£,  £&)  destroys  the  object  £  and  removes 
Its  descriptor  from  ££. 

read  (fla,  I,  j)  returns  the  value  of  the  j-th 
entry  In  the  I-th  descriptor  In  security  object  os. 
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write  (os.  I ,  J,  val)  sets  the  contents  of  Me 
j-th  position  In  the  l-th  descriptor  In  security  object  £2. 
to  val,  if  there  exists  an  l-th  descriptor. 

We  assume  that  the  above  programs  are  correct.  We  also 
assume  that  there  is  some  mechanism,  not  required  correct, 
by  which  a  user  program  may  communicate  Its  wishes  to  the 
update  program.  The  set  of  arguments  with  which  the 
update  program  must  be  invoked  are:  1)  the  name  of  the 
object  whose  descriptive  data  it  is  wished  to  change,  2) 
the  name  of  the  security  object  to  which  the  object 
belongs,  3)  the  operation  that  is  desired  (which  program 
to  invoke),  and  4)  the  relevant  input  parameters  to  that 
program  (the  desired  new  values  In  a  descriptor). 

It  should  be  fairly  straightforward  to  sketch  an 
update  program,  given  the  outline  in  the  meta  model  and 
the  above  correct  routines. 

.Theft  terns 

It  Is  now  necessary  to  specify  the  objectives  of  the 
system  design.  These,  In  some  reasonably  specific 
language,  are  the  criteria  to  which  it  is  desired  the 
system  conform.  We  first  state  the  requirements,  as 
currently  understood,  in  rather  Informal  English,  and  then 
begin  to  formalize  them  In  terms  of  the  specific  model  at 
hand.  These  requirements  are  relatively  simple,  and  do 
not  provide  some  of  the  guarantees  that  are  currently 
desired  by  some  segments  of  the  computer  community. 
However,  at  this  point.  It  Is  believed  that  current  and 
short  range  future  military  requirements  would  be 
satisfied.  Informally,  there  are  four  requirements.  1) 
No  user  shall  have  any  access  to  an  object  if  the 
sensitivity  rating  of  the  user,  at  the  time  that  Initial 
access  is  attempted,  is  less  than  the  sensitivity  rating 
of  the  object.  2)  No  user  shall  have  any  access  to  an 
object  If  the  set  of  compartments  associated  with  the 
object  at  the  time  of  Initial  attempted  access  Is  not 
contained  by  the  set  of  compartments  associated  with  the 
user.  3)  No  user  shall  have  any  access  to  an  object 
unless  authorized  by  a  "need  to  know"  specification  at  the 
time  of  Initial  attempted  access. 

The  problem  of  demonstrating  that  these  criteria  are 
always  applied  In  this  model  can  be  approached  in  the 
following  way.  First  prove  that  the  format,  or  structure 
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of  the  data  base  will  hava  the  properties  that  are 
'described  In  the  descusslon  earlier.  This  amounts  to 

-  proving  a  number  of  assertions  about  the  effect  of  the 
update  program. 

Then  state  theorems  one  through  three 
algorf thmical ly.  Modify  the  decision  process  In  the 
access  program  to  Invoke  the  above  algorithms  as  part  of 

-  the  decision  process  itself  In  such  a  manner  that  a)  It  Is 
:  simple  to  show  that  the  algorithms  are  always  applied  In 
-the  decision  process,  b)  the  parameters  they  are  supplied 

-  are  appropriate,  and  c)  the  result  of  the  algorithms  has  a 
controlling  effect  on  whether  or  not  access  Is  granted. 

As  an  example,  we  restate  the  first  two  requirements 
below,  using  the  notation:  sensitivity  (x)  and 

7  compartment  (x)  to  mean  the  sensitivity  and  compartment 

-  entry  In  the  descriptor  for  object  x,  respectively. 

-  proc  label -check  (user,  object); 

check  <-  true; 

If  sensitivity  (object)  >  sensitivity  (user) 
then  check  <-  false: 

If  compartment  (object)  <  compartment  (user) 
then  check  <-  false: 

LB. turn  check;  <f  . 

end; 


In  the  above,  the  symbol  >  means  the  binary 
arithmetic  operator  "greater  than".  The  symbol  $  Is  the 
negation  of  the  set  theoretic  property  of  "contained  In". 
It  is  presumably  clear  that  programs  for  all  of  the 
operations  and  checks  required  for  the  procedure 
label-check  are  straightforward  In  light  of  the  data  base 
provided  by  the  security  objects. 

The  decision  program  is  then  modified  by  replacing 

"relation  (...)"  by 

"relation  (reference,  user,  access  type)  and 
label  check  (user,  object)". 

.The  truth  of  the  three  requirements  can  be  guaranteed 
In  this  manner,  if  in  addition  a  consistent  data  structure 
Is  assumed  for  the  security  objects. 
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c*  This  approach  ts  equivalent  to  dynamic  checks  at  run 
time  of  the  state  of  the  system.  Certainly  It  Is  possible 
that  careful  construction  of  the  logical  structure  of  the 
system  could  obviate  the  need  for  some  run  time  checks/  In 
a  fashion  analagous  to  certain  programming  languages. 
While  that  approach  might  be  more  efficient/  these  checks 
do  not  appear  particularly  costly.  Also/  the  logical 
correctness  of  the  system  probably  could  be  more  easily 
demonstrated  under  these  circumstances/  particularly  in 
the  face  of  changes  to  the  system. 


The  preceding  sketch  has  been  Intended  only  as  a 
re sonablllty  argument  In  support  of  the  viability  of  the 
security  meta  model.  There  Is  no  claim  here  of  the 
accuracy  of  the  detail.  Rather/  It  Is  only  argued  that 
the  highly  modular/  tree  structured  proof  structure  for  a 
security  kernel  Is  a  viable  and  effective  manner  to  deal 
with  the  task  of  correct  security  system  design. 
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CHAPTER  1 


INTRODUCTION 


i  * 

’l.l  Secure  Operating  Systems  -  General  Goals 

The  security  aspect  of  shared  computer  systems  has  In  i 

the  past  not  received  preeminent  concern.  Questions  of  ! 

Efficiency  and  flexibility  have  forced  It  Into  the 
background  of  the  design  process. 

The  military/  however/  Is  faced  with  the  spectre  of 
Irrevocable  compromise  of  classified  Information/  should  a 
flaw  exist  in  the  system's  security.  A  single  cunning  and 
aailclous  user  may  employ  a  bug  to  penetrate  or  degrade  an 
essential  system/  which/  once  penetrated  in  secrecy  may 
even  be  covertly-and  continuously  tapped  for  Intelligence. 

As  an  example/  Goheen  and  Flske  (4)  report  a 
successful  penetration  of  an  IBM  System/360  operating  in  a 
classified  environment.  At  the  end  of  the  study,  the 
anti  re  system  was  essentially  open  to  the  penetrators  in 
complete  secrecy. 

In  the  past  the  military  has  Insured  protection  of  a 
sensitive  computer  facility  by  segregation  of  the 
equipment,  limiting  physical  iccess  to  the  equipment,  and 
forcing  on-site  usage.  Today  the  problem  is  to  insure 
security  in  a  modern  time-shared  multi-access, 
multi  programmed  system  in  which  remote  users  with 
different  clearance  levels  can  run  concurrently  with  data 
flies  and  programs  of  varying  clearance  levels. 

The  military  will  adopt  In  the  near  future 
extraordinarily  high  standards  for  security  certification 
of  equipment  and  software.  Some  steps  have  recently  been 
taken  toward  analysis  of  the  military  computer  security 
problem,  and  toward  articulating  methodology  for  designing 
certifiable  security  systems  <8),  (9),  (10). 

Schell  (10)  has  proposed  three  design  principles  for 
security  mechanisms:  complete  mediation.  Isolation  and 

jjpinllcltv: 

(1)  The  system  must  provide  Immediate  and  complete 
Halation  between  reference  to  and  retrieval  of 
Information,  validating  all  such  references  using  a 
special  subsystem. 
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(2}  This  subsystem/  the  "security  kernel",  must 
thwart  any  attempt  at  forgery  of  identity/  and  must 
protect  Its  own  validation  algorithms. 

(3)  The  security  kernel  must  be  simple  enough  for 
effective  logical  certification/  and  Implemented  in  a 
small  set  of  simple  primitive  operations. 

In  addition/  Schell  stated  a  robustness  criterion  for 
adjudging  the  effectiveness  of  kernel  operation:  It  must 
be.  "...so  designed  that  even  an  antagonist  could  provide 
the  remainder  of  the  system  without  compromising  the 
protection  provided." 

The  need  for  these  principles  can  be  seen  from  'the 
findings  of  the  OS/360  penetration  study  (4)/  where  lack 
of  a  centralized/  simple  and  certifiable  kernel  was 
adjudged  to  be  the  source  of  the  system's  vulnerability. 

In  Chapter  2  of  this  paper  we  propose  a  conceptual 
model  of  the  kernel's  operation  and  organization/  and  In 
Chapter  3  we  particularize  the  model  to  the  military 
security  problem.  Our  main  objective  is  to  design  a 
logically  verifiable  kernel  subsystem  to  guarantee 
operating  security. 

1.2  Design  Methodology 


We  Imagine  the  design  process  to  move  from  needs  to 
Implementation  In  a  series  of  levels  of  abstraction,  each 
level  moving  closer  to  a  concrete  machine  realization. 
The  topmost  level/  level  zero/  consists  of  a  mathematical 
model  of  general  protection  mechanisms/  Independent  of 
particular  security  requirements.  The  mathematical 
objects  In  the  level  zero  model  are  functions  which  are 
expressed  In  terms  of  (virtual)  primitives  unanalyzed  at 
level  zero.  That  Is/  at  level  zero,  the  security  kernel 
Is  factored  into  a  number  of  components  (modules).  Some 
components  remain  to  be  analyzed  further  in  lower  levels 
of  abstraction;  level  zero  describes  how  the  components 
synthesize  to  achieve  the  system  goal.  At  the  same  time/ 
subgoals  are  established  for  each  of  the  unanalyzed 
modules. 

At  level  1/  the  process  Is  repeated  on  each  of  the 
modules  unanalyzed  at  level  zero.  Level  1  codifies  the 
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specific  requirements  of  a  military  security  kernel,  and 
Identifies  still  "smaller1'  unanalyzed  primitive  components 
to  be  analyzed  and  factored  at  still  lower  levels. 

The  term  factorization  Is  appropriate  for  this 
process,  since  at  each  level  the  unanalyzed  components  do 
Indeed  compose  with  other  functions  In  order  to  realize 
the  goal  for  that  level. 


I  This  top-down  design  approach  allows  us  to  make 
I  design'  decisions  In  an  orderly  manner  —  the  choice  of 
r*  factors  or  modules  at  each  level,  and  the  scheme  of 

r  synthesis  amount  to  design  decisions,  and  determine 

constrained  subgoals.  The  approach  allows  us  to  separate 
i  issues  germane  to  protection  from  those  which  are 

'  particular  to  a  machine  or  system. 

By  far  the  most  Important  advantage  of  this  approach 
Is  that  It  allows  for  orderly  verification  of  each  level. 
Verification  proceeds  In  a  “bottom  up"  manner  at  each 
level:  assuming  that  the  unanalyzed  modules  behave  as 

hypothesized,  then  the  synthesized  function  at  the  level 
does  such-and-such.  Having  verified  the  level,  the 

Inductive  subgoal  Is  now  to  factor  and  verify  the  modules. 

At  level  2  we  envision  describing  level  1  In  terms  of 
a  MULTICS-1 Ike  file  directory  hierarchy.  The  notions  of 
directory,  segment  descriptor  and  process  descriptor  are 
Introduced,  but  "paging"  Is  Invisible  at  this  level.  Our 
task  at  level  2  will  be  to  show  that  a  file  directory 
hierarchy  structure  realizes  the  access  retrieval  function 
defined  at  level  1. 

Levels  zero  and  one  are  described  In  detail  In  the 
following  chapters.  We  believe  that  the  utility  of  the 
chosen  design  methodology  Is  Illustrated  In  these 
chapters. 
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CHAPTER  2 


LEVEL  ZERO 


2.1  A  Kernel  Model 

2.1.1  The  Accession  Relation  Components  flt  IhS.  Motift! 

We  employ  a  protection  model  based  on  the  work  of 
Lampson  (7)  and  Graham  and  Denning  (6).  We  have  a  set  of 
cucurltv  obiects  0  (files,  programs,  devices,  etc.)  a 
subset  S  of  the  set  0  of  subjects  (processes)  and  a  set  of 
a  of  access  attributes  (♦read1,  'write1,  ’control', 
'owner',  etc.).  Access  of  subjects  to  objects  Is 
controlled  by  an  access  Lon  relation  R  which  is  a  subset  of 
S  x  0  x  A.  For  example,  R  (s,o,a)  or  ”(s,o,a)  In  R"  is 
Intended  to  convey  that  s  has  attribute  a  with  respect  to 
object  o.  Lampson  regards  R  as  represented  In  the  form  of 
a  matrix. 


m:  S  x  0  ->  ><A) 

with  entries  In  the  power  set  P(A)  of  A.  We  wish  to 
postpone  questions  of  representation  until  later. 

In  this  model  we  assume  that  the  accession  relation 
Involves  a  single  subject  and  a  single  object.  That  Is, 
we  allow  in  our  system  a  relation  like 

(1)  "si  can  'read'  ol" 
but  not 

(2)  "si  can  'read'  ol  only  from  device  o2" 
which  would  involve  three  objects. 

Associated  with  each  type  of  object  is  a  monitor,  a 
program  which  actually  performs  the  desired  accession. 

Here  we  wish  to  Illustrate  the  difference  between  our 
visualization  of  the  security  system  and  that  of  Graham 
and  Denning. 

t 

In  their  model,  depicted  In  FIGURE  1,  when  a  subject 
s  initiates  access  a  to  object  o,  the  system  supplies  the 
triple  (s,o,a)  to  an  appropriate  monitor.  The  monitor 
interrogates  the  accession  "matrix"  to  determine  whether  s 
has  a  access  to  o  and.  If  so,  the  monitor  performs  the 
requested  function. 


C’-'  We  wish,  on  the  other  hand,  to  propose  a  picture 
which  Isolates  the  process  of  access  attribute  checking, 
and  which  separates  this  process  from  the  monitor 
functions.  This  effectively  factors  out  the  following 
processes:  the  Interpretat Ion  of  a  subject  request  with 
attendant  system  mediation,  the  search  for  and  retrieval 
of  access  attributes  (which  depends  upon  the  way  In  which 
the  Information  of  R  Is  stored),  the  checking  of  retrieved 
attributes  against  the  accession  request,  and  finally  the 
operation  of  individual  monitors*  The  situation  Is 
depicted  In  FIGURE  2. 

Below  we  address  the  questions  of  design  and 
certification  of  the  Access  Evaluator  (E),  the  Attribute 
Retriever  (F),  and  the  Update  Monitor  (U). 

-  We  do  not  Investigate  the  operation  of  G,  the  Access 
Request  Generator.  It  Is  the  mechanism  which  guarantees 
system  mediation  In  all  requests  for  protected  objects. 

As  the  entryway  Into  the  kernel,  G  must  provide  a 
requesting  subject  with  a  nonforgeable  Identification 
Interpreted  by  the  kernel. 

Neither  can  we  consider  the  operation  of  the 
monitors.  Being  concerned  with  security,  we  are 
fundamentally  Interested  In  forbidding  unauthorized  access 
to  any  supervisory  module.  Thu:,  we  do  not  address  the 
possibility  of  faulty  operation  of  the  monitors 
themselves.  The  correct  operation  of  the  security 
checking  mechanism  should  guarantee  that  no  program  can 
access  the  Ill-gained  fruits  of  a  monitor  bug. 

2.1.2  Accession 

When  a  program  requests  an  access  to  a  monitor,  it 
requests  that  a  service  be  performed  for  It  by  the  system. 
As  such  It  actually  requests  an  entry  to  the  monitor 
program. 

We  imagine  the  kernel  to  Interpose  Itsejf  between  the 
requesting  program  and  Involved  monitor.  The  kernel  must 
Interpret  the  type  of  request,  identify  the  objects 
Involved,  and  perform  the  requested  action  or  a  violation 
recovery  action.  It  Is  the  function  of  the  Access 
Evaluator  E  to  retrieve  appropriate  data,  grant  or  deny 
the  request,  and  transfer  to  the  appropriate  monitor  (the 
violation  handler  Is  considered  a  separate  monitor).  In 


FIG.  1.  GRAHAM -DENNING  MODEL 


FILE 


FIG.  2.  SECURITY  KERNEL  ORGANIZATION 


our  description  of  the  function  performed  by  E#  we  say 
that  function  e  returns  a  function  mx#  where  mx  Is  the 
function  performed  by  monitor  Mx.  We  use  upper  case  to 
denote  programs  (system  modules);  corresponding  lower  case 
to  denote  the  actions  (functions)  which  they  perform. 

Let  e  be  the  function  realized  by  program  E#  and  let 
f  be  the  function  accomplished  by  the  program  F  which 
fetches  the  accession  data.  Then 

e:  SxOxA  ->  {in(0)<in(l)7,Min(x^ 

f:  SxOxA  ->  B  (1) 

tells  us  some  Information  about  e  and  f  --  their  types . 

It  does  not  explain  the  details  of  thetr  action#  but  shows 
at  least  the  nature  of  their  Inputs  and  outputs. 

Given  the  required  accession  relation  R#  F  operates 
correctly  if  we  can  guarantee  that 

(X)  Vs. Vo. Va.  f(s#o#a)  -1 
Iff  R  (s#o#a). 

This  just  states  that  F  has  correctly  stored  and  correctly 
retrieves  the  accession  data. 

Suppose  h(o#a)  retrieves  the  Index  of  the  proper 
monitor  function  m(h(o,a))  among  m(l)# . . ,#m(x) .  For 
example#  If  o  Is  a  data  file  and  a  Is  'read'#  then  h(o#a) 
Is  the  index  of  the  file  system  manager. 


Assuming  f#h  are  verified  to  operate  correctly#  then 
e  can  be  correctly  realized  by 

e(s#o#a)  ■  JLt  f(s#o#a)  ■  1  then 
m(h(o#a))  el se  m(0). 

(lot ice  that  m  Is  a  mapping  which  takes  the  name  of  a 
monitor  program  and  returns  the  mapping  realized  by  this 
program.  In  an  implementation  this  might  mean:  fault  to 

an  appropriate  location  in  a  protected  program. 


(1)  B  »  fl#oJ  or  /true.fal se?  Is  the  set  of  bits. 
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Summarizing^  we  have  the  maps 


f:  SxOxA  ->  B 

h:  OxA  * )  fl/2/itifX| 

ms  .  ^*l/2/.../xJ  fm(l)/ .  •  •  /m(x) J 

m(t)s  unspecified  functions 

The 'arguments  and  values  of  the  m(t)  (their  types) 
depend  upon  their  respective  duties/  and  clearly  Involve 
data  external  to  the  kernel.  For  example/  the  memory 
addressing  hardware  monitor  will  need  to  know  where  In  the 
requesting  program  to  return  the  contents  of  an  address. 

By  leaving  these  details  unspecified/  the  most  we  can  say 
Is 'that  e  returns  one  of  a  finite  set  of  explicit 
functions.  Further  analyses  may  now  enumerate/  factor  and 
describe  the  Implementation  of  the  m(i).  What  we  have 
done  Is  to  get  them  out  of  the  access-checking  game, 
concentrating  on  their  "natural"  roles. 

Returning  to  the  question  of  certification/  what  If 
(1)  Is  violated/  l.e./  f  does  not  adequately  reflect  the 
desired  accession  relation  R?  Popek  (9)  has  suggested 
(the  inclusion  technique)  that  we  add  to  the  antecedent  of 

e 

I f  f ( S/ 0/ e)  ■  1  then  ... 

all  of  the  extra  checks  demanded  by  R/  after  writing  a 
suitable  routine  d  to  store  and  retrieve  these  checks.  We 
will  then  have  another  program 

e'(S/0/e)  •  JLt  f(S/0/e)  «1  and  d(s/0/e)  «1 

then  . . . 

which  will  now  operate  correctly.  But  this  amounts  to 
constructing  a  retrieval  function  f*  satisfying 

f(S/0/e)  •  f  (S/O/e)  And  d(S/0/e) . 

What  Is  evidently  needed  Is  a  correct  retrieval  function  f 
satisfying  (1).  In  a  practical  system/  It  Is  the 
structure  of  f  which  Is  of  utmost  Importance  anyway. 


In  a  later  sactlon  we  analyze  the  function  f  with 
particular  emphasis  on  a  military  security  model ,  and 
Introduce  the  notions  of  locks  and  keys  In  the  operation 
of  f. 

*  '  i 

2.1.3  llodatlon 

As  the  system  evolves  over  time,  the  security  state, 
represented  by  the  accession  relation  R,  Is  modified  by 
the  attentions  of  the  update  monitor  U.  Available  for  the 
use  of  subjects  are  various  security  state  uodatlon 
commands  (delete,  grant,  destroy,  etc.)  which  request 
changes  to  attributes,  destruction  of  subjects  and 
objects,  etc. 

•  ...  *  , 

A  destroy  subject  s2  command  by  subject  si  Is,  for 
example.  Interpreted  by  G  as  a  request  to  write  to  the 
(protected)  accession  data  F.  The  Information  (si,  F, 
'write')  Is  passed  to  the  Access  Evaluator  E  which 
determines  whether  si  is  allowed  to  change  any  Items  at 
all  In  F.  If  control  Is  passed  to  U,  U  must  now  do 
further  careful  checking  to: 

(a)  retrieve  the  name  of  the  particular  subject 
s2  which  Is  to  be  destroyed; 

(b)  determine  whether  si  Is  allowed  to  destroy 
s2; 

(c)  perform  the  desired  action,  or  else  refuse, 
with  attendant  action. 

Operation  (a)  Is  performed  with  no  difficulty,  but 
operation  (b)  requires  some  explanation.  The  Internal 
logic  of  U  determines  the  type  of  access  attribute  si 
needs  vis-a-vis  s2  In  order  to  destroy  s2,  say  'owner'.  U 
then  Interrogates  F  with  the  request  (si, s2, 'owner' ),  and 
If  this  triple  Is  part  of  the  current  security  state,  U 
then  updates  F  In  the  required  fashion  (deleting  s2  from 
the  data  base)  and  passes  control  to  further  non-kernel 
systems  for  housekeeping  duties. 

The  monitor  U,  being  Inside  the  kernel.  Is  "trusted" 
by  E,  and  there  Is  no  need  for  U  to  go  through  G  or  even  E 
In  order  to  access  F.  Hence  U  may  successfully  "disguise" 
Itself  as  si  for  purposes  of  reading  si's  privileges. 
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Other  types  of  updatlon  can  be  handled  In  a  similar 
fashion. 


Notice  that  In  this  model  the  detailed  study  of 
F*updatlon  privileges  Is  done  by  U,  which  must  take  Into 
consideration  a  larger  context  of  Information  than  E;  but 
U  has  F  at  Its  disposal. 


The  correctness  of  an  Implementation  of  U  depends 
upon  a  full  description  of  the  circumstances  under  which 
the  system  Is  to  honor  a  request  to  alter  the  security 
state.  These  circumstances  are  Imposed  on  the  design  from 
without.  In  the  form  of  a  set  of  updatlon  constraints.  It 
must  be  demonstrated  that  any  change  which  U  makes  results 
In  an  acceptable  security  state  within  the  updatlon 
constraints. 


Updatlon  constraints  are  described  In  a  logical 
language,  and  codify  just  those  rules  which  the  designer 
wishes  to  place  upon  U  In  its  making  of  updatlon 
decisions. 


Associated  with  each  updatlon  command  Is  a  predicate 
true  If  and  only  If  the  command  can  legally  be  executed  by 
the  requesting  process. 


Example:  delete  ( *  read* ,s2,o)  Is  a  command  uttered  by  s 
and  asking  that  attribute  'read'  be  withdrawn  from  s2 
vis-a-vis  o.  There  Is  an  associated  predicate 


DEL  SSxAxSxO. 


DEKsl, ' read' ,s2,o)  Is  true  If  and  only  If  si  Is  allowed 
to  delete  s2's  'read*  privilege  to  o. 


An  example  of  an  updatlon  constraint  Is: 


Vsl.Vs2  fR(sl,s2, 'control ' )  — > 
Vo.Va  DEL  (sl,a,s2,o)} 


which  says  in  words  "For  every  si  and  s2,  if  si  has 
'control'  access  to  s2,  then  for  all  objects  o  and 
attributes  a,  si  can  delete  s2's  a-access  to  o."  Or 
better:  "If  si  has  'control'  of  s2,  then  si  can  delete 
any  of  s2's  privileges  to  any  object." 


in 
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Other  examples  follow  which  may  readily  be  translated 
by  the  reader: 

Vsl. Vo. CR(sl,o, 'owner')  -> 

Vs2.Va.GRANT(sl,a,s2,o)3 

Vs. Vo£R(s,o,  'owner')  ->  DESTROY  (s,o)3 

Within  U  are  a  series  of  programs,  called  uodators. 
Wl, . * . ,Wz.  These  effect  the  actions  requested  In  the 
command*  by  users.  The  actions  they  perform  are  denoted 
wl,..,wz.  U  also  has  as  a  factor  a  program  V,  the 
Constraint  Checker,  which  matches  an  updatfon  request 
against  the  updation  constraints,  suitably  Internalized. 
FIGURE  3  Illustrates  the  situation,  and  FIGURE  3a  shows 
the  parallel  nature  of  E  and  U. 

V  employs  the  retrieval  program  F  to  make  Its 
decisions.  Its  Internal  logic  should  be  designed  from  the 
(fixed)  updation  constraints  as  outlined  above.  Obviously 
Its  operation  cannot  be  Illustrated  without  a  predefined 
set  of  constraints  to  work  from.  However  we  can  give  an 


JjumBle  Suppose  we  have  tie  updation  constraint 

Vs.Vo.R(s,o, 'owner' )  ->  DESTROY(s,o) 

and  let  W2  be  the  "destroyer"  program.  Then  the 
description  of  V  will  Include  In  part  the  line 

...  Xt  f(s,o, 'owner')  ■  I 
then  w2  ... 

As  In  the  case  of  e,  v  outputs  one  of  a  set  of  functions 
wl,...,wz. 

Now  providing  that  V  operates  according  to  the  given 
constraints  and  provided  that  the  Individual  updators 
perform  their  assigned  tasks  correctly,  U  will  operate 
correctly,  and  the  system  will  never  enter  a  state  which 
compromises  security.  Why?  A  correct,  satisfactory,  or 
secure  system  Is  defined  by  the  set  of  updation 
constraints.  U  merely  enforces  them. 
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FIG  3.  UPDATE  MONITOR 


FIG  3a.  KERNEL 
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All  the  above  assumes  that  the  constraints  form  a 
consistent  set.  For  an  example  of  an  inconsistent 
constraint  set.  Imagine  both 

"si  may  never  a-access  o3" 

and 

Vs£GRANT(sO,s,a,o3)3. 

Then  It  Is  clear  that  sO  could,  quite  Innocently,  grant  si 
access  a  to  o3. 

No  kernel  or  system  will  ever  be  able  to  enforce  an 
Inconsistency. 

Clearly  a  design  prereaul s I te  Is  a  complete 
description  of  commands  and  their  logical 
Inter-relationships,  expressed  In  the  updatlon 
constraints.  This  "requl rements"  list  must  first  be 
checked  for  consistency.  Provided  It  is  so,  V  may  be 
encoded  to  check  that  each  constraint  Is  satisfied  for 
each  updatlon  request.  This  provides  another  example  of 
Popek's  (9)  Inclusion  Technique. 

2.2  Modeling  Access  Data  Retrieval 

In  this  section  we  focus  upon  the  operation  of  the 
retrieval  program  F.  We  give  some  attention  to  the 
possibilities  of  factoring  this  program  Into  (perhaps) 
more  simply  verifiable  components. 

The  function  of  F  Is  to  represent  and  retrieve  the 
Information  contained  In  the  accession  relation  R  -  the 
security  state  of  the  system.  Since  the  numbers  of 
subjects  S,  objects  0,  and  access  attributes  A  are  all 
finite,  R  Is  In  principle  "just  a  big  table"  and  F  "just 
a  big  table  look-up".  This  might  satisfy  an  automata 
theorist  but  not  a  systems  designer. 

(1)  First,  there  is  an  enormous  amount  of 
Information  contained  In  R  —  the  triples  (s,o,a)  not  In  R 
are  as  important  as  those  la  R. 

(2)  Second,  R  is  sparse  as  a  table,  or  even  as  a 
matrix 

r:  SxO  ->  P(A) , 
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suggesting  that  In  practical  cases  a  great  dealfof 
structural  constraint  obtains  among  the  entries. 


(3)  Third,  the  amount  of  Information  Is  so  large 
that  present-day  systems  employ  both  dynamic  and  static 
storage  techniques  In  Its  retrieval.  For  example,  in  the 
MULTICS  segmented  memory,  with  Its  dynamic  linkage 
facility,  part  of  the  protection  Information  Is  stored  In 
the  environment  of  a  process;  the  rest  Is  distributed 
throughout  the  storage  system  and  available  for  later 
dynamic  recall.  In  future  systems  there  may  well  be  a 
requirement  to  segment  this  Information  base. 

(4)  Fourth,  people  group  and  use  Information 
according  to  behavior  patterns  and  In  established 
structures.  For  example,  very  few  systems  development 
programmers  call  a  linear  regressions  package,  and  many 
data  files  group  naturally  together  with  the  associated 
project  which  developed  them. 

For  all  these  reasons,  we  believe  in  careful 
structuring  of  the  program  F  with  a  view  toward  certifying 
Its  operation.  Below  we  make  a  start  toward  this 
analysis. 

2.2.1  A  Model  for  Data  Configuration 

2. 2. l.i  Mathematical. . Language 

In  this  model  we  do  not  discuss  Issues  of 
Implementation,  but  do  wish  to  develop  a  theory  for  the 
structuring  of  data  used  In  the  security  kernel. 

From  our  point  of  view,  set  theory  is  not 
an  adequate  tool  for  the  expression  of  notions  In 
computing.  The  most  primitive  semantic  notion  for 
programming  Is  that  of  function  or  mapping.  A  set,  as  a 
primitive,  orderless  collection  can  never  be  realized  on  a 
computer,  whereas  a  function,  the  characteristic  function 
of  the  set,  can  be  so  Implemented.  That  is,  set  S  cannot 
be  "In”  the  machine,  but  a  map  c:  S->B  can  be  realized  as 
a  bit  string  If  the  size  of  S  Is  small;  as  a  linked  list 
If  large,  etc. 
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If  S,T  are  finite  sets,  (S->T)  represents 
the  set  of  all  possible  maps  from  S  to  T.  The  statement 

ct  S->B 

means  that  c  Is  1q  (S->B),  a  set.  Whenever  we  write 
f:  (A->B)->C  or  say  **f  In  <<A->B)->C)H,  we  are  expressing 
the  type  of  f  as  a  mathematical  object.  This  gives  only  a 
limited  amount  of  Information  about  f  —  its  domain  and 
range  —  but  Is  frequently  useful. 

« 

Another  concept  used  all  the  time  is  that 
of  cross-product  of  two  sets  SxT.  Since  this  is  just  a 
set  and  not  representable  on  a  machine,  we  think  of  It  as 
a  function 

p:  SxT->B 

defined  to  give  1  for  all  pairs  In  SxT. 

On  a  machine  we  cannot  really  make  sense  of 
an  ordered  pair.  Pairs  must  be  stored,  and  In  some  order. 
We  adopt  the  fact  that 

(SxT->U>  -  <S-XT->U>>. 

That  Is,  by  convention  an  S,T  matrix  of  U-values  Is  stored 
as  an  S-llst  of  T-llsts  of  U's. 

2. 2. 1.2  Examalca 

We  give  here  some  examples  of  the  way  In 
which  F  might  be  arranged  as  a  program. 

gx.  a.  A  security  system  using  Access  Control  Lists 
(ACLs) . 

The  accession  relation  is  stored  by  object, 
then  subject,  then  attribute.  The  accession  function  Is 


f:  0->  <S-XA->B)> 


Given  an  o  In  0, 


f  (o) :  $-XA->B) 
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Is,  an  ACL  —  the  ACL  of  o  —  and  is  Itself  a  function. 
Given  a  subject  s ,  fCo)  finds  an  access  attribute  list 

(junction* 

f (o)(s):  A->B 

associated  with  o  and  s.  This  list  might  be  represented 
as  a  bit  string.  The  point  is  that  f(o)(s),  given  an  a, 
returns  a  bit.  How  it  does  this  is  Implementation.  A 
pictorial  diagram  of  the  above  might  be  given  for  MULTICS 
In  FIGURE  4. 


f(01)  (SI) 
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The  bundles  of  linking  arrows  represent  the  functions 
f,  f(o),  f(o)(s),  and  may  not  be  simple  pointers,  but  some 
complex  hashing  scheme. 

Notice  that  tn  MULTICS,  the  object  collection  Itself 
has  a  further  structure,  the  file  dl rectory  hierarchy,  not 


shown  here 


Ex.  b.  A  System  with  Capability  Lists  (C-lists) 

R  Is  stored  by  subject,  then  object,  then 
attribute: 


f:  S-XO-XA->B>> 

The  C-l I st  for  subject  si  1a  a  map 
f(sl):  0-XA->B) 

which  returns,  for  an  object  o2  a  map 
f(sl)(o2):  A->B 
the  attribute  list. 

An  oversimplified  example  Is  given  from  MULTICS  In 
FIGURE  5. 

Multlcs  actually  consists  of  a  complex  of  both 
techniques.  Initially  the  system  checks  the  descriptor 
segment  for  an  object.  If  It  Is  not  present,  a  missing 
segment  fault  occurs,  the  file  directory  hierarchy  Is 
searched  for  the  object  and  the  descriptor  segment  Is 
updated  with  the  object  identification  and  access 
Information. 


2.2.2  Generalized  Locks  and  Kevs 

2. 2. 2.1  Definitions 

Frequently  the  sparse  structure  of  R  or  any 
of  Its  representations  discussed  above  can  be  exploited  to 
factor  the  retrieval  problem.  Indeed,  both  natural 
groupings  of  subjects  (think  of  projects)  and  natural 
groupings  of  objects  (think  of  master  files)  may  exist. 

The  Idea  of  key  and  lock  exploits  this  observation:  why 
treat  each  subject  or  object  as  a  separate  security 
entity,  when  coarser  groupings  may  be  more  efficient? 

Let  K  be  a  finite  set  of  keys,  L  a  finite 
set  of  locks.  The  only  thing  we  require  is  that  these 
sets  consist  of  distinguishable  objects  (e.g.,  bit 
positions  In  a  word).  A  kev  assignment  is  a  map 
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FIG.  5 

k;  S  ->  (K->BJ 
and  a  lock  assignment  a  map 
1:  0  ->  (1->B) . 

A  subject  may  thus  be  issued  several  keys;  and  an 
object  may  have  several  Independent  locks. 


We  also  have  an  unlocking  relation  which  tells  which 
keys  are  adequate  to  which  locks 

t:  KxL  ->  <A->B>. 

This  Is  not  a  one-to-one  relation,  nor  even  a  function; 
for  a  passkey  may  open  many  different  locks,  and  a  lock 
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may  be  opened  by  a  hierarchy  of  passkeys  of  varying  power 

/ 

Subject  s  has  access  a  to  object  o  If  and  only  if 
there  are  kl,12  such  that 

k(s)  <kl)  -1, 

Ho)  (12)  -1 

and  f 

t  <kl,12>  (a)  -1. 


SUBJECTS 


KEYS 


LOCKS 


OBJECTS 


FIG  6. 

We  may  depict  an  accession  relation  as  in  FIGURE  6. 

Notice  that  any  accession  relation  represented  using 
Intermediate  locks  and  keys  can  of  course  be  realized  by 
an  accession  matrix 
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m:  SxO  ->  (A->B) 


Merely  by  defining  m(s)(o)(a)»l  if  and  only  if  there  are 
kl,12  such  that  k(s)(kl)al,  l(o)(12)«l  and  t(kl,12)  (a)*l. 
But  this  misses  the  point.  Locks  and  keys,  which  look 
like  a  fatuous  complication  in  the  abstract,  are 
introduced  in  practice  for  natural  reasons  leading  to 
greater  efficiency,  in  an  application  it  may  prove  more 
efficient  to  calculate  k,  1 ,  and  t  than  to  look  up  entries 
in  a  tree  structure  such  as  those  of  2. 2. 1.2. 

_  2.2. 2. 2  Example;  A  Mill tar^  Securi tv  Model 

In  an  application,  the  notions  of  lock  and  key  rqay  be 
used  to  store  one  component  of  the  accession  information, 
while  other  techniques  are  used  for  the  remainder. 

Possibly  complex  overlays  of  various  storage 
representations  may  be  used  if  efficiencies  result.  The 
problem  of  a  military  security  data  base  is  a  good 
example. 

Three  factors  govern  the  control  of  access  to 
protected  information. 

(a)  clearance/c las  sJ  f i cat  ion.  A  document,  file 
or  program  (Information)  is  Slid  to  be  classified  U,C,S  or 
TS.  A  user  or  subject  is  saici  cleared  for  U,C,S,TS. 

Belov/  we  represent  these  security  levels  by  integers 

0,1, 2, 3. 


(b)  compar tmental ization.  As  a  refinement  of 
(a).  Information  and  users  are  further  assigned  one  or 
more  compartments,  reflecting  the  kinds  of  classified 
information  to  which  they  belong  or  have  access.  The 
military  employs  16  compartments  Pa£l,..,16j,  e.g., 
cryptographic,  AEC,  etc. 

(c)  need  to  know.  The  finest  resolution  of  the 
security  question  occurs  at  this  level.  For  each  subject 
s  and  object  o,  the  military  requires  that  some  authority 
grant  s  an  "a-need  to  know"  for  o  before  s  can  a~access  o. 
Examples  might  be  "need  to  read",  "need  to  execute",  etc. 
From  our  point  of  view,  the  various  "needs  to  know"  are  an 
application  of  the  notion  of  access  attribute  for  a 
subject/object  pair.  The  information  is  stored  in  the 
underlying  accession  relation  for  the  system. 


Clearance/class tf teat  Ion  may  be  modeled  by  the 
following  lock/ key  arrangement  (the  key/ lock  functions  are 
denoted  by  the  same  symbol  in  this  example). 

ct  S->C  - 
c:  0->C 
t*  C  x  C  ->B 

where  C*£0,1,2,3J  and 

% 

t(l,j)-l  if  and  only  If  12J. 

Compartmenta! izatlon  Is  represented  by 

t  pt  S-XP->B> 

p:  0-XP->B) 
z:  <P->B)  x(P->B)  ->B 

where  z(p(s),p(o) )*1  tf  and  only  If  p(s)  and  p(o)  -  p(s). 
Here  and  represents  the  bit  mask  of  lists. 

Final ly,  as  noted  above,  need~to-know  must  be  handled 
by  explicit  retrieval,  structured  however  is  convenient. 

He  depict  the  situation  In  FIGURE  7. 
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CHAPTER  5 


A  MILITARY  SECURITY  MODEL 


The  purpose  of  this  chapter  Is  to  propose  the 
requirements  of  a  military  time-sharing  system  operating 
In  multilevel  security  mode.  DOD  5200. 28-M  defines 
multilevel  security  mode  as: 

"A  mode  of  operation  under  an  operating  system 
...  which  provides  a  capability  permitting  various  levels 
and  categories  or  compartments  of  material  to  be 
concurrently  stored  and  processed  In  an  ADP  system.  In  a 
remotely  accessed  resource-sharing  system,  the  material 
can  be  selectively  accessed  and  manipulated  from  variously 
controlled  terminals  by  personnel  having  different 
security  clearances  and  access  approvals..." 

The  model  will  be  Independent  of  Implementation  In 
the  sense  that  It  will  be  possible  to  Interpret  the  rules 
of  the  kernel  as  being  enforced  by  a  human  security 
officer  handling  documents,  not  necessarily  by  a  computing 
system.  The  model  will  be  formulated  ustng  existing 
military  security  requirements  for  document  control  (AFM 
205*1),  as  well  as  requirements  which  have  been 
established  for  existing  military  computer  systems  (WWMCCS 
GCOS,  DOD  5200. 28-M).  Below,  In  referring  to  the 
manual  system,  we  shall  mean  present  military  procedures 
for  physically  handling  classified  documents,  as  specified 
In  AFM  205-1. 

3.1  General  Considerations. 

3.1.1  Three  Dimensions. of  Security 

In  the  military  three  factors  control  access  to 
protected  Information,  as  discussed  in  section  2. 

3. 1.1.1  Clearance/Class  If icatlon 

Possible  clearances  are<£c»  0,1,2,33.  With  each 
object  Is  associated  a  clearance  or  classification  via  the 
map. 
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3. 1.1. 2  Compartmentallzatlon 

Compartments  are  P«fl,2, . . . #16} .  Each  object  ts 
assigned  to  a  list  of  compartments  by  the  map. 

p:0-XP->8> 

Thus  If  o  is  In  0,  p(o):  P->B  ts  o's  compartment 

list. 


«a 


3. 1.1. 3  Needs-to-Know 


We  regard  this  as  equivalent  to  the  notion  of 
access  attribute.  Given  an  attribute  set  A  (discussed 
below)  the  function  f :0-XS-XA->B))  assigns  to  each 
object  o:0  a  list  of  needs-to-know  f(o):S*>(A->B) 
classified  by  subject.  Notice  that  we  are  proposing  an 
Access  Control  List  structure  for  f  (Cf.  section 
2. 2. 1.2). 

Evidently  clearance  and  compartment  Information 
could  be  stored  Implicitly  tn  the  access  retrieval 
function  f  (Cf  section  3.2.3).  However,  for  purposes  of 
access  checking  and  updating  this  would  neither  be 
efficient  nor  would  It  model  the  existing  military  manual 
system.  As  a  consequence  we  factor  the  accession  data  as 
Indicated. 

3.1.2  System  vs.  User  Responsibility 

In  designing  requirements  for  a  military  multilevel 
security  system,  we  must  decide  at  the  outset  the  role  of 
the  kernel  In  transactions  Involving  secure  data. 

a)  The  Responsible  Kernel 

t 

The  kernel  Itself  Is  responsible  for  the 
control,  classification,  declassification  and  manipulation 
of  information  within  the  system.  It  employs  automatic 
rules  to  assign  classifications  to  newly  created  files, 
maintains  a  history  of  each  user's  security  environment 
and  watches  each  user  to  maintain  operating  consistency. 
This  approach  Is  Illustrated  tn  Weismann's  paper  (11). 

The  kernel  from  this  point  of  view  becomes  a  super 
bureaucrat. 


b)  The  Responsible  User 

/ 

The  assumption  Is  that  an  authorized  user  of 
classified  Information  has  full  responsibility  for  Its 
control  while  operating  with  It.  Thus  destruction  of 
copies,  reclassification  of  altered  files,  etc.,  become 
duties  of  the  user  which  must  be  performed  before  he  logs 
off.  The  kernel,  after  granting  Initial  access,  makes  no 
attempt  to  monitor  the  use  to  which  data  Is  put. 

•  . 

Whichever  role  the  kernel  Is  designed  to 
play,  the  system  of  rules  which  the  kernel  enforces  must 
be  simple  enough  and  so  clearly  stated  that  each  user 
understands  the  full  Implications  of  each  security  state 
updatlon  command,  and  his  responsibilities  In  employing 
It. 

The  assumption  of  user  resoonslbl 1 Itv  Is  the 
one  which  agrees  most  readily  with  the  present  manual 
system,  and  will  underlie  the  design  discussed  here. 

As  a  consequence  of  the  "responsible  user11 
assumption,  certain  possible  "security  compromises"  of 
concern  to  Lapadula  and  Bell  (?)  are  neither  detected  nor 
prevented  by  our  proposed  system.  To  use  their  example, 
suppose  si  Is  cleared  for  TS,  s2  for  S  and  let  file  o3  be 
classified  S.  Suppose  si  wrltss  some  top  secret 
Information  In  o3,  but  falls  to  explicitly  upgrade  o3's- 
classification.  The  kernel  cannot  detect  the  "violation". 
At  some  future  time,  s2  could  be  granted  'read'  access  to 
o3,  and  s2  would  be  reading  "forbidden"  Information. 

Our  feeling  Is  that  any  attempt  to  make  the 
kernel  responsible  for  detection  and  prevention  of  such 
occurrences  would  either  (I)  Involve  the  kernel  In 
deciding  complex  questions  of  sensitive  data  aggregation, 
or  would  (II)  require  the  adoption  of  an  arbitrary 
"hlgh-watermark"  rule  (e.g.,  si  operating  under  a  TS 
clearance  can  only  write  TS  files).  The  latter  approach 
Is  adopted  by  Wetssman  (11),  who  does  not  allow  for  the 
possibility  of  declassifying  files. 

Here  we  only  require  the  kernel  to  enforce 
existing  manual  security  regulations  which  place  the  onus 
of  responsibility  upon  the  user  of  a  document  to  make 
necessary  changes  to  Its  classification  or  compartments. 
Since  we  demand  that  the  kernel  allow  reclassification  on 
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some  authority,  compromises  of  the  kind  Illustrated  above 
will  always  be  possible  on  some  level.  We  have  chosen  to 
trust  completely  every  authorized  user.  The  kernel  Is 
* non-susplctous  —  If  a  subject  is  granted  access  rights  by 
-the  kernel,  the  subject  has  the  full  Implications  and 
-responsibilities  attendant  on  those  rights. 

~  Another,  more  technical,  way  of  phrasing  this 

^1s  that  the  kernel  uses  only  subject/object  ID's, 
classifications,  compartment  lists,  and  access  attributes 
In  reaching  its  decision.  The  kernel  does  not  interpret 
-or  deduce  any  Implications  from  an  authorized  access  or 
update  request. 

tor  example.  If  si  accesses  an  object  o~2  for 
which  It  has  inadequate  clearance,  a  security  violation 
occurs.  But  If  si  obtains  upward  reclassification  from  an 
"incompetent"  but  authorized  subject  s2,  and  then  accesses 

-  o2,  no  violation,  from  the  system  standpoint,  has 

-  occurred. 


3.1.3  Separat-lQn__Qf_  Access  I  on  and  Updatlon 

As  discussed  In  the  previous  chapter,  the  processes 
of  granting  "normal"  access,  and  the  granting  of  updates 
must  be  kept  distinct,  since  the  latter  action  is  more 
complex.  It  fol  lov/s  that  the  data  used  and  modified  by 
the  updation  procedures,  the  accession  relation  R,  should 
be  kept  distinct  from  ordinary  protected  data  files.  For 
one  thing.  It  will  have  to  be  maintained  In  a  rigid  format 
Interpretable  by  the  kernel.  For  another  thing.  It  Is 
part  of  the  kernel  Itself,  since  its  compromise  would 
compromise  the  entire  system.  Lastly,  it  may  be  stored  In 
a  radically  different  manner  -  perhaps  In  special 
hardware. 

In  our  model  this  data  is  stored  in  the  access  data 
retrieval  program  (F).  We  see  no  reason  to  treat  it  as  an 
object  (compare  Popek's  (9)  security  objects),  since  It 
deserves  such  special  status. 

3.1.4  'Control'—atid-'-Owner'  Access  Attributes 

The  notions  of  'control'  and  'owner'  access 
attributes  occur  In  Lampson  (7)  and  Graham  and  Denning 
(b) .  One  subject  si  'controls'  another,  s2.  If  si  can 
read  from  and  write  In  s2's  row  of  the  matrix  m:S  -> 
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0->(A->B),  l.e.  If  si  can  read  and  modify  s2 * t r 
capabilities.  If ,  In  addition,  si  may  destroy. s2  or  grant 
to  other  subjects  any  access  to  s2,  then  si  Is  said  to 
have  'owner'  access  to  s2.  Thus  si  'owns'  s2  when  si  may 
read  from  and  write  In  s2's  co 1 umn  of  the  access  matrix. 
Issues  Immediately  arise  concerning  multiple  'owners'  and 
the  transferabl 1 1 ty  of  'control ',  which  are  surveyed  by 
Graham  (5). 

We  .shall  not  Introduce  these  attributes.  The 
relation  of  si  'owning'  s2  can  be  replaced  by  granting  si 
all  possible  attributes  for  s2.  Obviously  then,  multiple 
'owners'  are  possible. 

If  si  can  'control'  s2,  this  Implies  that  si  .can' 
obtain  and  modify  all  s2's  caoabl 1 1  ties  -  the  list  of  all 
objects  Ifl  which  s2  has  access.  In  our  model,  access 
attributes  will  be  stored  in  ACL  form  (Section  2.1.2, 
example  a).  There  is  no  way  for  si  to  conveniently  learn 
s2's  privileges,  short  of  listing  all  objects  and 
requesting  the  ACL  of  each.  (This  Is  exactly  the 
situation  in  MULTICS.)  We  see  no  apparent  reason  for 
Introducing  the  'control'  facility. 

Furthermore,  In  the  military  manual  system, 
possession  of  document  Implies  "control"  of  It  and 
responsibility  for  it.  A  possessing  subject  can  give  it 
away,  garble  It,  etc. 

Vile  choose  to  Introduce  the  simple  attribute  'update'. 
Subject  si  with  'update'  attribute  for  o2  (subject  or 
not),  may  modify  the  security  data  concerning  o2  (access 
attributes  Jta  o2,  clearance,  compartments).  There  will  be 
no  facility  for  one  subject  si  to  affect  a  second 
subject's  attributes  vis-a-vis  an  object  o2,  unless  si  has 
'update'  permission  for  o2.  When  si  has  'update' 
permission  for  s2,  si  can  only  limit  accesses  by  other 
subjects  s2. 

Update  permission  may  be  passed  to  other  subjects 
like  any  other  attribute. 


3.2  Elements  of  the  Model 


3.2.1  Access  Attributes  (A) 

The  set  A  consists  of  five  attributes 
A«fr,e,w,u,  1? 


with  the  following  meanings: 

Attribute  a  If  f(o)(s)(a)«l  then 

r  s  can  read  the  contents  of  object  o , 

-Implying  that  s  can  copy  o. 

scan  execute  the  (executable)  object 
o.  s  must  know  the  calling  sequence 
for  o ,  since  s  cannot  read  o. 

.ji  can  write  to  o ,  altering  It,  adding 
"to  It,  even  zeroing  It  out. 

s  can  update  (write  on)  the  descriptor 
(see  section  3.2.4  below)  of  o,  adding 
to  It  or  deleting  from  It. 

s  can  look  at  the  contents  of  the 
descriptor  (see  section  3.2.4  below) 
of  o,  without  affecting  Its  contents. 

3.2.2  Modes  (K) 

The  mode  (1)  of  an  object  Is  an  Indicator  of  the  kind 
of  object  It  Is  —  terminal,  process,  data  file, 
directory,  etc.  Depending  on  the  characteristics  of  the 
computer  system,  there  may  be  different  modes,  each 
usually  associated  with  a  special  subsystem  or  monitor  for 
handling  objects  of  the  same  mode.  We  choose  a  mode  set 
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(1)  Called  by  Burke  (2)  a  type.  We  have  used  type  in  a 
more  technical  sense,  so  we  employ  Popek's  (9)  term  mode. 


,  ita  i  rnw  w-- — ■< 


K"ft,P,f  ,dj 


and  a  function  k:0->K  assigning  to  each  object  an  unique 
mode,  with  the  following  meanings: 


Itade  K1 


a  terminal 


a  process,  I.e.,  a  subject 


a  file,  i.e.,  a  protected  block  of 
data  not  Interpretable  by  the 
system. 


a  directory,  a  specially  formatted 
file  which  may  be  Interpretable  by 
the  system. 


Other  modes  may  be  Introduced  depending  upon  the 
particular  system. 


3.2.3 


In  the  military  security  model,  the  data  used  by  the 
kernel  to  determine  privileges  Is  stored  In  a  factored 
accession  matrix,  as  In  section  2. 2. 2. 2.  We  represent  It 
by  the  three  functions 


fsO-XS-XA->B)) 


c:0->C 


p:0-XP->B) 


where 


C«fO,l,2,35 

A»£r,e,w,u,l3 


There  are  three  different  relations,  all  devoted  by  £, 
which  will  be  useful  below: 


(I)  i:  C  x  C->B 
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denotes  the  usual  inequality  on  Integers. 

(ID  is(P->B)  x  <P->B>  ->  B 

denotes  the  subset  relation  on  the  compartment  lists 
object  r  ts  a  member  of  (P->B).  (1) 

(III)  <A->B)  x  <A->B)  ->  B  '  ■  ' 

denotes  the  subset  relation  on  access  lists:  object 
a  Is  a  member  of  (A->B). 

A  convenient  abuse  of  notation  will  allow  us  to 
Identify  sets  In  P(A)  with  functions  in  (A->B).  For* 
example,  £uj,  which  usually  denotes  the  singleton  set  fuj 
In  P(A),  will  mean  for  us  the  function  £uJ:A->B  given  by 

fuj(x)*l  If  x»u 
0  if  xpu 

Either  point  of  view  Is  seen  to  be  equivalent,  but  we 
believe  that  the  "list"  notation  (A->B)  is  more 
suggestive. 

3.2.4  Pe scrip tars 

A  useful  auxiliary  notion  Is  that  of  descriptor  of  an 
object,  as  used  by  Popek  (9).  For  each  o  In  0,  d(o),  the 
descriptor  sit  fl,  Isa  quadruple  of  functions 

d(o)a(c(o),  p(o),  fCo),  k(o)) 

or,  equivalently 

d(o)(l)«c(o) 

i 

d(o)(2)-p(o) 
d(o) ( 3)-f (o) 
d(o)(4)*k(o) 


(1)  The  notations  P(A),  2  exp  A,  and  (A->B)  may  all  be 
considered  equivalent.  We  use  (A->B)  because  it  reminds 
us  we  are  dealing  with  functions. 
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Thus  d  has  type 

d:0->C  x  (P“>B)  x  (S-XA->B) )  x  K 

This  Is  one  way  to  model  the  storage  of  access  data.  A 
descriptor  is  a  sort  of  generalized  Access  Control  List 
(ACL)#  and  is  particularly  appropriate  when  a  MULTICS-llke 
file  directory  hierarchy  is  contemplated.  Descriptors  are 
then  naturally  stored  as  elements  of  directory  segments. 

While  at  this  stage  nothing  forces  us  to  introduce 
the  notion  of  descriptor#  it  will  be  convenient. 

3.2.5  The  Access  Evaluator  (E) 

Normal  accession  requests#  not  Involving  updatlon# 
pass  through  E#  whose  function  is  easily  described.  In 
our  informal  programming  language#  we  shall  be  sure  to 
declare  the  types  of  all  functions  mentioned  In  the 
program.  Let  M-fm(O)#  m(l># . . .m(x)?  be  the  set  of 
monitors#  m(0)  the  violation  hendler#  m(l)»V  the  access 
checker.  Let  h:0  x  A->fl#2# . . be  such  that  h(o#u)«l 
for  all  o  In  0. 

e(sl#ol#b) 

e:  S  x  0  x  A->’1 
si:  S 
cl:  0 
b:  A 

f:  0->(S-XA->B>) 
c:  0->C 
p:  0-XP->B> 
h:  0  x  A->fl#2 #...? 
m:  f 0#1#2# . . ,$->M 
£:C  x  C->B 

i:(A->B)  x  (A->B)  ->B 
2:<P->B)  x  <P->B)  ->B 
If  c(sl)2.c(ol)  and  p(sl)2.P(ol) 
and  f<olMsl>2tbJ 
then  m(h(ol#b)) 
else  m(0) 

end  e 

3.2.6  jjadation  Commands 

A  user  program  desiring  to  effect  changes  to  the 
descriptors  requests  the  kernel  to  perform  the  service  for 
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him  by  Issuing  an  updatlon  command.  The  updatlon  program 
verifies  the  user's  authority  to  make  the  change,  and 
performs  the  service  for  him  using  Its  updators. 

The  commands  and  their  Intents  are: 

Command  intent 

write  (o,s,a)  sets  the  access  list  f(o)(s) 

*  to  a:A*>B,  destroying  the  previous 

list. 

read  (o,w)  writes  clearance,  compartment, 

access  list  and  mode  of  o  In  w* 


clear  (o,n)  sets  the  clearance  of  o  to  n, 

destroying  the  previous  value. 

compt  (o, r)  sets  the  compartment  list  of  o  to 

the  list  r:P->B,  destroying  the  old 
list. 

create  (0,2)  creates  an  unique  ID  for  o  and 

associated  descriptor  with  C(o)-0, 
p(o)<*9  full  access  privileges  for 
creating  subject  and  K(o)«z. 

destroy  (o)  nullifies  the  descriptor  of  o, 

erases  the  ID  and  the  object 
contents. 

3.2.7  Uodators  (Wi) 

1 

These  are  the  kernel  programs  which  actually  perform 
operations  on  the  descriptors,  and  which  call  any  further 
system  monitors  needed  for  allocation,  garbage  collection 
etc.  There  will  be  an  updator  corresponding  to  each 
command: 

wr,  rd,  cl,  cp,  cr,  and  ds 

The  constraint  checker  V  calls  the  updators,  as 
Illustrated  In  the  next  section. 


r  .In  the  programs  below  we  shall  not  again  declare 
C/P#f#^m<0) .  Two  functions  mentioned  below  make(o)  and 
break(o)  are  left  undefined.  .They  are  responsible  for 
housekeeping  duties  associated  with  creation  and 
destruction  of  objects 


V(sl, request, ol,s2,al,w,n,z,r) 

•  sl:S  *  ; 

s2:S 
ol:0 

request: fwr l te, read,cl ear, compt, create, destroy/ 
al:A->B 

w:C  x  <P->B>  x  <S-XA->B))  x  K 
.  >  n:C 

r:P->B  , 

z:K  1 

If  request»'wrl te' then 
begin 

If  c(sl)2c(ol)  and  p(sl)2P(ol)  and 
f (ol)(sl)2!ui  and  c(s2)2c(ol)  and 
p(s2)2p(ol>  and  not  (ol»s2  and  al2fuj) 
then  wr(s2,ol,al) 
else  m(0) 

end  i 

else  If  request  «  'read'  then 
begin 

if  c(sl)J>c(ol)  and  p(sl)2P(ol) 
and  f(ol)(sl)2fl! 
then  rd(ol,w)  i 

else  m(0) 

end 

else  If  request  ■  'clear1  then 
begin 

if  c(sl)2n  and  c(sl)2c(ol) 
and  p(sl)2PCol)  1 

and  f(ol)<sl)2tuJ 
then  cl  (ol,n) 
else  m(0) 
end 

else  if  request  a  'compt'  then 
begin 

If  p(sl)2r  and  c(sl)2c(ol)  and  f (ol>(sl)2*u) 
then  cp  (ol,r) 
else  m(0) 
end 
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else  If  request  ■  'create*  then  cr(ol,sl,z) 

else  If  request  ■  'destroy'  then 

begin  , 

If  c(sl)2c(ol>  and  p(sl)2p(ol) 
and  f (ol)(sl)2fu3 
then  ds(ol) 

end 

else  m(0) 
end  V 

wr  (s2,ol,al) 
s2:S 
ol:0 
al:A->B 
f(ol)(s2X-al 

end  wr 

rd  (ol/w) 

ol:0 

w:  C  x  (P->B)  x  (S-XA*>B))  x  K 
w  <-  <c(ol>,p(ol>,f<ol>,mCol)> 

end  rd 

cl  (ol,n) 

ol:  0 
n:  C 

c(ol)<-n 

end  cl 

cp  (ol,r) 

ols  0 
rs  P->B 
p(ol)<-r 

end  cp 

cr  <ol, si, z) 
ol:  0 
si:  S 
z:  K 

make  (ol)  . 

f(ol)(sl)  <-  fr,e,w,u, Ij 
c(ol )  <-  0 
p(ol )  <-  l 
k(ol)  <-  z 

end  cr 
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ds  (ol) 


end  ds 


ol:  0 
f (ol)<-0 
c(ol)<-0 
p(ol)<-0 
break(ol) 


3.3  Requirements  of  Mltltary  Security 


The  security  state  (1)  of  the  system  at  any  tlme.i  is 
described  by  the  classifications/  compartments  and 
attributes  of  all  the  objects 

q(l)  ■  (C/P/f) 

The  system  is  initialized  (n  some  state  q(o)/  (2)  and  by 
servicing  updation  commands  evolves  to  security  states 
q(l)/q(2)/ . . .etc. 

Given  certain  security  criteria  to  be  discussed 
below/  our  problem  is  to  show  that  the  system  maintains 
these  criteria.  This  entails  two  demonstrations 

(I)  Accession.  Between  changes  In  security 
state/  i.e./  while  the  system  occupies  security  state 
q(l)/  the  kernel  enforces  security  requirements  based  upon 
privileges  (and  prohibitions)  implied  in  q(i).  (e.g./  "no 


privileges  (and  prohibitions)  Implied  in  q(t).  (e.g./  "no 
s  can  read  o  unless  f(s)(o)  2.  f rj"), 

(it)  Updation.  In  honoring  a  command  and 
updating  from  q(i)  to  q(i+l)/  the  kernel  observes  any 
updation  constraints  required  by  the  performance  criteria 
(e.g./  "no  subject  may  alter  Its  own  security 
classification".') 


(1)  This  is  Identical  to  Lapadula  and  Bell's  (8)  notion  of 
security  state  (p.  18)  except  for  their  component  b. 

(2)  A  typical  q(0)  would  have  one  subject  sO  the  system 
administrator  with  full  privileges  to  alt  system  objects. 
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If  (i)  and  (ft)  can  be  demonstrated,  then  by 
Induction  on  i,  the  system  remains  secure  over  time  —  no 
sequence  of  access  requests  and  updation  commands  can 
Induce  the  kernel  Into  a  "security  compromise."  (1) 

Before  we  can  demonstrate  (i)  or  (II),  we  must 
delimit  the  criteria  or  rules  which  the  kernel  must 
enforce.  Another  way  to  say  this  Is  that  we  must  define 
"security  compromise". 

% 

It  is  here  that  debate  will  occur  over  what 
requirements  to  properly  put  upon  the  kernel.  Based  upon 
the  tenet  of  "user  responsibility"  discussed  above,  we 
will  list  a  reasonable  set  of  rules  demanded  by  military 
users.  In  section  3.3.2  we  discuss  the  impl  icat  ipns  ~of 
our  rules,  and  In  section  3.3.3  we  discuss  possible 
alternatives. 

The  dichotomy  (!),(!!)  shown  above  breaks  the 
criteria  naturally  Into  two  parts  -  those  regarding  normal 
accession,  and  those  regarding  updation. 

3. 3. 1.1  Accession. 

Let  q  ■  (c,p,f)  be  a  security  state  of  the 
kernel.  The  rules  are 

(a)  No  s  shall  have  any  access  to  an  o 
unless  when  access  Is  requested 

c(s)2,c<o)  and  p(s)j>.p(o) 

(b)  No  s  shall  be  able  to  read,  write  on, 
execute,  update  the  descriptor  of  or  look 
at  the  descriptor  of  an  object  o  unless 

f(o)(s)2f»*?,  fwj,  fej, 

{u?  or  flj,  respectively. 


(1)  The  notion  of  compromise,  and  the  picture  of  the 
system  as  an  automation  evolving  over  time  with  command 
Inputs,  Is  due  to  Lapadula  and  Bell  (8). 
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Proposition  Provided 

. Or  • ' 

(I)  all  requests  for  access  by  subjects  to 
•  'objects  are  directed  to  the  kernel 

*  *  *  i  ♦  ■ 

(It)  the  kernel  correctly  retrieves  and  1 

Interprets  the  arguments  of  a  request 

/  ! 

| (III)  .the  kernel  correctly  Identifies  the 
subjects  and  objects  Involved  In  a  request 

-  -  then  , 

the  system  satisfies  rules  (a)  and  (b). 

Proof.  Consider  the  Access  Evaluator  program  e.  Subject 
s  cannot  access  object  o  unless  a  system  monitor  performs j 
the  function  for  It.  But  e  is  Interposed  between  all 
calls  by  s  and  the  monitor.  If  (I),  (II)  and  (III)  hold, 
e  blocks  access  of  any  kind  unless  c(s)2c(o)  and 
p(s)2p(o),  showing  (a)  holds.  Given  a  request  b  6  j 

fr,w,e,u, 1?,  access  to  m(h(o,b})  Is  blocked  unless 
f (o)(s)2.fb5,  so  (b)  holds. 

Q.E.D. 

3. 3. 1.2  Updatlon 

We  list  the  updatlon  constraints  which 
should  operate  in  a  military  environment 

i  '  i 

(c)  No  s  may  alter  the  descriptor  of  an  object 
o  unless  f(o)(s)2fuf. 

(d)  No  s  may  alter  or  read  the  descriptor  of  an 
object  o  unless  c(s)J>c(o)  and  p(s)2.p(o) , 

(e)  No  access  attributes  may  be  granted  by  si 
to  s2  for  o  unless 


c(s2)2.c(o)  and  p(s2)2p(o) 

(f)  No  s  may  alter  Its  own  descriptor. 

Proposition.  Under  the  provisos  (I)  (II)  (III)  above  and 
provided  that  In  the  initial  security  state  q(0)  we  do  not 
have  f (s)(s)2.fu J  for  any  s,  then  the  system  satisfies 
rules  (c),  (d),  (e),  and  (f). 


.  A  qA  * 

Proof.  Consider  the  Update  Constraint  Checker  program  V. 
Vie  take  each  rule  In  turn: 

(c) .  Descriptors  may  only  be  altered  via  the 

updators  wr,  cl/  CP/  ds ,  The  only  calls  to  these 
functions  occur  from  clauses  preceded  by  an  expl Iclt  check 
for  f(o)(s)2fu/.  , 

(d) .  Descriptors  may  only  be  altered  or  read  by  wr, 
cl/  cp/  ds,  rd.  Each  Is  called  from  a  clause  which 
explicitly  checks  for  c(s)2c(o)  and  p(s)2P(o). 

(e) .  si  can  grant  s2  attributes  for  o  only  by  a  call 
to  wr(o,s2,-).  This  call  occurs  only  in  a  clause  preceded 
by  the  explicit  check  c(s2)2.c(o)  and  p(s2)2p(o).' 

(f) .  s  could  alter  its  own  descriptor  only  by 
calling  wr,  cl,  cp,  or  ds  on  o»s,  but  each  such  call  is 
preceded  by  an  explicit  check  for  f  (s)  (slifuj.  Therefore 
if  we  can  show  that  it  Is  never  possible  to  enter  a 
security  state  with  f(s)(s)2fuj  for  any  s,  we  are  done. 

Uy  hypothesis  in  q(Q)  we  have  no  s  with  f  (sMsJifuJ. 
Suppose  it  were  to  occur  in  some  q(i),  and  let  i  be  the 
first  such  i.  Then  in  q(l-l)  not  f(s)(s>2  fuj.  Hence  V 
must  have  serviced  a  command  at  i  resulting  in  wr(s,s,al) 
with  al2fu£.  Out  the  call  to  wr(s2,ol/al)  is  preceded  by 
on  expl lei t  check  not  (ol»s2  and  al^fuj)  which  Is 
violated  by  ol*s2>s  and  al^fuj.  Thus  we  cannot  have 
f(s)(s)2fuj  in  q( I )  or  in  any  successor  state  of  q(0). 

(f)  follows. 

Q.E.D. 


3.3.2  Implications.  External  Breaches. 

In  stating  requirements  (a)  to  (f)  we  have  in 
effect  defined  the  notion  of  internal  security  compromise 
-  a  compromise  caused  by  the  system's  failure  to  meet 
responsibilities.  Certain  compromises  of  security  in  a 
larger  sense  can  still  occur  through  actions  not  under  the 
control  or  scrutiny  of  the  kernel.  Examples  of  such 
external  breaches  are: 

(1)  A  3-cleared  user  si  with  r  access  to 
3-classl f I ed  file  ol  copies  ol  to  o2,  classifies  o2  at  0 
level,  and  grants  read  access  to  s2.  User  s2  is  cleared 
only  to  0.  Even  if  the  system  could  prevent  direct 
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"moving"  of  files  in  such  cl rcumstances,  si  could  still 
bypass  the  system  by  processing  ol  Into  an  altered  form 
before  copying  to  o2,  could  aggregate  sensitive  totals 
from  ol  and  copy  them  in  o2,  etc.  No  system  could 
interpret  all  such  possible  evasions.  Even  If  it  could/ 
si  could  still  act  by  collusion  as  the  direct  agent  of  s2. 
Evidently/  If  si  has  privileged  access  to  ol/  no  kernel 
can  keep  him  from  abuse  of  his  trust. 

An  alternative  to  this  approach  Is  to  force  created 
flies  to  be  classified  at  the  high  watermark  level  of  the 
environment  of  si.  Then  either  explicit  declassification 
is  prohibited/  or,  if  not/  this  precaution  is  vacuous  and 
at  best  a  default  convenience. 

Me  choose  to  accept  the  axioms  of  complete  trust  in  a 
prlvlllged  user  vilthin  the  limits  of  his  privileges  and 
complete  responsibility  of  the  user  in  assigning 
classifications/  compartments  and  attributes  to  files  to 
which  he  has  fuj  privilege. 

(2)  A  user  si  with  clearance/  compartments 
and  M  access  for  ol  can/  even  without  ful  access,  alter 
ol  beyond  repair/  in  effect  destroying  it.  There  is 
therefore  a  good  case  for  Identifying  the  fwj  and  fuj 
attributes/  merging  them  Into  a  single  fw/  attribute.  The 
design  of  e  and  V  could  be  easily  altered  to  accomodate 
this  design  decision/  with  essentially  no  changes  In  the 
arguments  of  section  3.1. 

Another  argument  in  favor  of  w**u  is  from  user 
responsibility.  If  si  can  write  In  ol/  si  ought  to  be 
able  to  reclassify  ol/  since  si  may  well  have  appended 
sensitive  information  to  ol. 

(3)  A  user  si  with  u  to  o3  can  provide 
another  (suitably  cleared)  user  s2  with  any  privileges  to 
o3  he  himself  possesses/  except  si  cannot  grant  fu/  for  s2 
to  s2.  Prodigal  use  of  this  facility  by  si  may  result  In 
an  external  breach,  but  the  system  cannot  be  responsible 
for  making  such  distinctions. 

3.3.3  AUernatiYA  .Kernel  Designs. 

Certain  other  design  possibilities  can  be 
handled  with  case  in  our  framework.  In  each  case  they 
entail  slight  alterations  of  the  e  and  V  programs. 
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(1)  Identifying  fw J  wi th  fu l .  This  was 
discussed  In  section  3.3.2.' 

(2)  Allowing  any  subject  si  with  fbj 
attribute  for  ol,  but  v/ithout  fu/  attribute,  to  pass  fb/ 
to  other  subjects.  This  Is  similar  to  the  'transfer' 
ability  of  Graham  and  Denning  (6).  First  we  declare  the 

funct I  on 


U  :  (A->B)  x  (A->B)  ->  (A->B) 

as  the  bitwise  "or"  of  attribute  lists.  Then  we  alter  the 
first  conditional  of  V  to  read 

If  requesta'wr 1 te'  then 
begin 

If  c(sl)J>.c(ol)  and  p(sl)>.p(ol) 
and  f  (ol )  (  si  )J>fu  1  and 
c(s2)2c(ol)  and  p(s2)2P(ol) 
and  not  (ol  =  s2  and  al2fu£) 
then  wr  (s2,ol,al) 
else  If  c(sl)2c(ol)  and  p(sl)>.p(ol) 
and  f(ol)(sl)2al  and  c(s2)2c(ol) 
and  p(s2)2P(ol) 

then 

begin 

al<-al  U  f(ol)(s2> 
wr(s2,ol/al) 

end 

else  m( 0) 
end 

else  If  request  »  'read'  then  ... 

(3)  Allowing  more  limited  updation 
privileges  than  those  implied  by  fuj.  Thus  f  (ol )  (  si  )>.fn/ 
night  allow  si  to  change  only  access  attributes  to,  but 
not  clearance  or  classification  of,  object  ol  while 
f(ol)(sl)2fj/  would  be  needed  to  reclassify. 

(4)  Enforcing  a  requirement  that  each 
object  ol  have  an  unique  'owner'  (Graham  and  Denning  (6), 
p.  420.).  We  can  capture  this  idea  by  allowing  only  one 
si  to  have  fuj  to  ol.  Assuming  this  is  the  case  In  the 
Initial  security  state  q(0),  we  build  into  V  the  checl; 

If  request  =  'write'  then 
begin 
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ir  c(sl)2c(ol)  and  p(sl)2p(ol) 
and  f (ol) (sl)2fuj  and 
c(s2)2c(ol)  and  p(s2)2p(ol) 
and  not  al£.?uj. 
then  w r  (s2,ol,al) 
else  m(0) 
end 

Then  an  inductive  argument  shows  that,  since  fuj  can  never 
he  "passed",  no  ol  ever  has  more  than  one  s  with 
f (ol)(s)J>fuJ.  Since  every  created  object  has  a  default 
"owner"  Cits  creator),  the  uniqueness  requirement  is 
proved. 


(5)  In  the  view  of  Burke  (2)  access 
privileges  granted  to  si  for  ol  should  depend  upon  the 
mode  rn(ol).  For  example  it  is  meaningless  to  grant  fcj 
access  to  a  data  file.  Thus  he  proposes  that  the  kernel 
at  update  time  check  m(ol)  and  grant  only  the  appropriate 
attributes . 

By  adding  further  conditionals  to  the  updators  we  can 
accomodate  this  constraint.  For  example  wr  may  be  altered 
to 


wr  Cs2,ol,al) 

if  m(ol)-p 

then  f(ol)(s2)<-  alnfe,u,l? 
else  if  m(ol)**f 

then  f  (ol)  (s2X-al  n  £r,w,u,  1^ 
etc 


•  •  • 
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